qucs-devel — Development related topics. Please subscribe before posting.

Re: [Qucs-devel] build modular qucs

[Felix S. <fe...@sa...>]

On Thu, Dec 09, 2021 at 02:05:11PM +0100, Erik V wrote:
> make error modular
> 
> /usr/bin/ld: cannot find -lqcustomplot

Thanks for reminding me. It's a bug. The qcustomplot-based diagrams
should not be built by default. Will fix this.

Workaround for now: apt install libqcustomplot-dev.

Best wishes
felix

Re: [Qucs-devel] build modular qucs

[Erik V <843...@gm...>]

make error modular

/usr/bin/ld: cannot find -lqcustomplot
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:540: diagrams.la] Fout 1
make[3]: Map '/home/test/DEV-QT/qucs-git-c94f20/build/plugins/diagrams'
wordt verlaten
make[2]: *** [Makefile:420: all-recursive] Fout 1
make[2]: Map '/home/test/DEV-QT/qucs-git-c94f20/build/plugins' wordt verlaten
make[1]: *** [Makefile:565: all-recursive] Fout 1
make[1]: Map '/home/test/DEV-QT/qucs-git-c94f20/build' wordt verlaten
make: *** [Makefile:467: all] Fout 2

greatings,
Erik

2021-12-08 15:51 GMT+01:00, Erik V <843...@gm...>:
> Dear Felix,
>
> The url https://git.code.sf.net/p/qucs/git qucs is not the branch
> modular but the 0.0.19 see VERSION file and /qucs VERSION file
>
> This is the file of the branch modular go to
> https://sourceforge.net/p/qucs/git/ci/modular/tree/
> Download Snapshot
> and you see in VERSION	 0.1.0
>
> Erik
>

Re: [Qucs-devel] build modular qucs

[Erik V <843...@gm...>]

Dear Felix,

The url https://git.code.sf.net/p/qucs/git qucs is not the branch
modular but the 0.0.19 see VERSION file and /qucs VERSION file

This is the file of the branch modular go to
https://sourceforge.net/p/qucs/git/ci/modular/tree/
Download Snapshot
and you see in VERSION	 0.1.0

Erik

Re: [Qucs-devel] build modular qucs

[Felix S. <fe...@sa...>]

On Tue, Dec 07, 2021 at 04:04:35PM +0100, Erik V wrote:
> compiling error Modular
> The HTTPS access git clone https://git.code.sf.net/p/qucs/git qucs-git
> are the same Modular and master.
> I have now download the Download Snapshot modular.

Not sure what you are doing exactly. It is easier to diagnose if you
give all details.

The following sequence works for me. Not showing the output.

$ git clone https://git.code.sf.net/p/qucs/git qucs --branch modular
$ cd qucs
$ ./bootstrap
$ mkdir build; cd build
$ ../configure
$ make -j18
$ make check -j18

Best wishes
felix

[Qucs-devel] Port to Qt5

[Niels M. <sof...@gm...>]

Hi all,

Thanks for developing Qucs. I was trying to gauge the status of a Qt5 port. Judging by the number of Qt5 branches, work has been done. My main questions are: is this port still underway? And how can I help speed this along?

Regards,
Niels.

[Qucs-devel] contributing

[Dow D. <DOW...@ms...>]

Hi,

I'm interested in contributing to Qucs.  I've been reading the documentation and source code, going back through the forum and reading open issue threads and roadmaps so I have some sense of the history of the project and its current goals.  I have some experience in C++ development, and am currently studying electronics (and using Qucs to get a deeper understanding of some circuits and components), but have limited knowledge -- especially of high frequency circuits.  I'm happy to help any way I can;  I can work independently, but will gladly accept any guidance offered.

In my recent testing of Qucs, I ran across a few issues (FreeHDL, ASCO) for which I now have temporary workarounds in place locally (e.g. GHDL and modified qucsdigi) so that I can continue testing.  Most of the documentation was helpful, but some parts could be improved (e.g. textmode.pdf).  I've forked the repo and am ready to begin generating commits and pull requests on the development branch to code and/or documentation if it would be of help.  If so, any guidance on priorities or structural goals would be much appreciated.

Best,
Dow

Re: [Qucs-devel] qucs on Raspberry Pi 4 4GB

[Dieter D. <die...@ya...>]

 
Thank you for your answer. ps2pdf (ghostscript) was already installed. 
So this is not correlated with the challenge, that symbols of the standard parts library (par example bridges, LED) are missing. 

That point was more an information for you that people will get recommendations which guides to a wrong direction. 

$ sudo apt-cache search ps2pdf
pod2pdf - Plain Old Documentation to Portable Document Format converter
texlive-latex-extra - TeX Live: LaTeX additional packages
texlive-latex-recommended - TeX Live: LaTeX recommended packages

Background is, that ghostscript is refered by LaTeX packages too. 

Regards,
Dieter


On Monday, January 4, 2021, 10:20:57 PM GMT+1, Reinhard Kotucha <rei...@we...> wrote:


On 2021-01-04 at 12:45:54 +0000, Dieter Drewanz via Qucs-devel wrote:


> $ sudo apt-get install ps2pdf
> not found


ps2pdf is part of ghostscript. Just install ghostscript.

Regards,
 Reinhard

--
------------------------------------------------------------------
Reinhard Kotucha Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover mailto:rei...@we...

------------------------------------------------------------------
  

Re: [Qucs-devel] qucs on Raspberry Pi 4 4GB

[Reinhard K. <rei...@we...>]

On 2021-01-04 at 12:45:54 +0000, Dieter Drewanz via Qucs-devel wrote:

 > $ sudo apt-get install ps2pdf
 > not found

ps2pdf is part of ghostscript.  Just install ghostscript.

Regards,
  Reinhard

--
------------------------------------------------------------------
Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:rei...@we...
------------------------------------------------------------------

Re: [Qucs-devel] QUCS Development

[Felix S. <fe...@sa...>]

On Thu, Dec 17, 2020 at 12:34:38AM +0400, Sergey Brutyan wrote:
> I want to develop new version of Qucs with integrating Verliog and FPGA
> programming abilities for Xilinx. I found in Qucs you have Verilog support.
> Which also have ability of signal analysis and MCU/CPU simulation.

Dear Sergey.

Thanks for your interest in Qucs.

Qucs is undergoing some refactoring at the moment. Please familiarise
yourself with the roadmap [1]. Future Qucs will be modular, on top of a
vendor-neutral ui/schematic library and a bunch of plugins that
implement applications similar to the ones you suggest.

The timeline for completion is open ended, but you are welcome to
contribute [2], test drive, debug or propose extensions that may or may
not require changes. I am happy to discuss such changes or requirements
that go beyond the scope of the replacement of the current "Qucs 0.0.20"
shapshot (as time permits).

> Please help with documentations as I have problem on compiling Qucs and
> getting Doxygen documentation. Also I want to make some major changes in GUI
> and add more tiles for embedded Linux development such as OpenWrt.

In order to answer to this, more details are required. Major GUI changes
need to be made consistent with the redesign of the library or they
cannot be included. What are tiles?

cheers
felix


[1] https://github.com/felix-salfelder/qucs/blob/refactor%2Bqt5/ROADMAP
[2] https://github.com/felix-salfelder/qucs/blob/refactor%2Bqt5/CONTRIBUTE

[Qucs-devel] qucs on Raspberry Pi 4 4GB

[Dieter D. <die...@ya...>]

Hello Qucs Developper and Maintainer,

This week I tried to install qucs from the sources (actual tarball rc2 from github). It did different attemps to get it running. One hard thing to figure out was that there is necessary to have added "sudo apt-get install texlive-lang-german". Without this you are lost in case configure & make will do making the docs too.

This I had to do different additionally too: 
$ sudo apt-get install ps2pdf
not found
$ sudo apt-cache search ps2pdf
pod2pdf - Plain Old Documentation to Portable Document Format converter
texlive-latex-extra - TeX Live: LaTeX additional packages
texlive-latex-recommended - TeX Live: LaTeX recommended packages
$ sudo apt-get install texlive-latex-extra
(45MB additional archives)

It is an Raspberry Pi 4 4GB RAM
$ uname -a
Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
$ cpp --version
cpp (Raspbian 8.3.0-6+rpi1) 8.3.0

Did a new try. Now with rc2 of 0.0.20 files.
./bootstrap: ends with an error.
./configure --disable-doc
make

Simulation with lumped components works.
Qucs is then working but still library extended symbols like bridge of diodes are missing.

This will show, which are missing:
https://steemit.com/utopian-io/@thinkingmind/qucs-suggestion-5-or-add-a-feature-that-can-view-component-picture-and-symbol-in-qucs-library
The symbol will not put in the circuit. See screenshot I have added. 

For that I do not have a solution now. Would be nice if anybody could give an advice how to solve this. 

Greetings
Dieter

[Qucs-devel] QUCS Development

[Sergey B. <bru...@gm...>]

Hi dear Qucs team let me introduce to myself, I am Sergey I work several 
years on Linux/ARM development in Armath 
<https://www.youtube.com/watch?v=weu0zjEWpOo&t=1s> project 
<https://www.youtube.com/watch?v=kIRAH7yp7j8>.

Armath <https://www.youtube.com/watch?v=kIRAH7yp7j8> is very generic 
project, with several components also including Linux/ARM development.

During the R&D process of Engineering laboratories development we found 
that we need more complex and modern tool. We use Qucs as a main circuit 
development environment and want to improve it and make it as a complete 
signal analysis tool such a LabView and circuit simulator like Proteus.

Now I study in European University which is located in Armenia Yerevan, 
and in University we want to open Linux/ARM/FPGA/RISCV laboratory. To 
incubate Linux/ARM developers.

I want to develop new version of Qucs with integrating Verliog and FPGA 
programming abilities for Xilinx. I found in Qucs you have Verilog 
support. Which also have ability of signal analysis and MCU/CPU simulation.

During long time research I found AVR simulator for Linux but it doesn't 
have GUI.

Please help with documentations as I have problem on compiling Qucs and 
getting Doxygen documentation. Also I want to make some major changes in 
GUI and add more tiles for embedded Linux development such as OpenWrt.

Please HELP.


P.S. Here I also attach my CV

-- 
Best Regard. Sergey Brutyan

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sun, Dec 06, 2020 at 11:45:55AM +0100, Martin Marmsoler wrote:
> But having a lot of libraries makes it more complicated, because in every
> library all qt dependencies must be added

I dont understand cmake very well. the autotools build uses a common.mk
file (think of it as plugins.mk, but it is not used like that). I'm sure
you could implement it in a similar way with cmake.

NB: there is only supposed to be one library. the other shared objects
are plugins.

thanks
felix

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sun, Dec 06, 2020 at 12:51:55PM +0100, Martin Marmsoler wrote:
> So we can also use external libraries to create diagram. Sou the wheel must
> not be reinvented.

Hi Martin.

It is a side effect, but yes. Use whatever you think solves your
problem, and whatever you are used to.

The key really is to split it off the library, from the start. This way,
choices will not have to be hard wired. Needless to say: this can be
tricky. Having seen a lot of code & ideas going down the drain (and
wheels reinvented) I believe that this is worth it.

Several contributions we have seen to Qucs in the last decade were of
the type "look, I have a proof of concept for $this, and it works for me
[tm]". It then sits there and bit rots, as the author does not have time
to mantain it. A plugin can be used by anybody, from day 0. Ideally
without modification to the rest of Qucs.

cheers
felix

Re: [Qucs-devel] Project structure

[Martin M. <mar...@gm...>]

But having a lot of libraries makes it more complicated, because in 
every library all qt dependencies must be added

add_library(paintings OBJECT ${PAINTINGS_HDRS} ${PAINTINGS_SRCS}
                              ${PAINTINGS_MOC_SRCS})
target_link_libraries(paintings Qt5::Widgets)


In labplot, where I did a lot, we put every file into a single 
CMakeLists.txt

https://invent.kde.org/education/labplot/-/blob/master/src/CMakeLists.txt

So when changing qt version, only in a single file the dependencies must 
be changed.


add_library( labplot2lib STATIC ${LABPLOT_SRCS} ${BACKEND_SOURCES} 
${NSL_SOURCES} ${CANTOR_SOURCES} ${DATASOURCES_SOURCES} 
${COMMONFRONTEND_SOURCES} ${TOOLS_SOURCES} ${GENERATED_SOURCES} 
${QTMOC_HDRS} )
target_link_libraries( labplot2lib
KF5::Archive
KF5::Completion
KF5::ConfigCore
...
Qt5::Sql
${GSL_LIBRARIES}
${GSL_CBLAS_LIBRARIES} )



On 06-12-2020 11:39, Felix Salfelder wrote:
> You may notice whist making CMake work. I don't remember how i did it
> with autotools.

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sun, Dec 06, 2020 at 11:29:19AM +0100, Felix Salfelder wrote:
> On Sun, Dec 06, 2020 at 11:18:26AM +0100, Martin Marmsoler wrote:
> > Yes I understand, but qucs/qucs depend on them or not? So if they are used
> > only by qucs, why they should be moved out?
[..]
> there will be a directory with the library (e.g. qucs/src) and plugins
> are in the directories next to it, e.g. qucs/legacy, qucs/diagrams,
> qucs/contrib.

Note that there is also a technical reason for this. on some platforms
you need to build the library before you can build plugins. This is
easier to accomplish (and less error prone) if things are in separate,
rather than nested directories.

You may notice whist making CMake work. I don't remember how i did it
with autotools.

cheers
felix

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sun, Dec 06, 2020 at 11:18:26AM +0100, Martin Marmsoler wrote:
> Yes I understand, but qucs/qucs depend on them or not? So if they are used
> only by qucs, why they should be moved out?

Hi Martin

(not exactly sure what you mean)

Nothing really depends on plugins. (Future) Qucs depends on plugins as
much as python depends on a program written in python.

there will be a directory with the library (e.g. qucs/src) and plugins
are in the directories next to it, e.g. qucs/legacy, qucs/diagrams,
qucs/contrib. currently the set of plugins loaded at startup is
hardwired in qucs/main/main.cc, but will change as soon as necessary.

thanks
felix

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sun, Dec 06, 2020 at 09:22:51AM +0100, Martin Marmsoler wrote:
> Why the diagrams are legacy? Does it mean the will be rewritten completely?

Hi Martin.

Diagrams dont work yet. Several options:

- carry on without Diagrams for now.
- try to make the legacy diagrams work.
- rewrite them (I think they should use Qt widgets, and Qt
  implements plotting these days).

Whichever happens first. See diagrams/README.

thanks
felix

PS: qucs/diagrams needs to move one level up.

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sat, Dec 05, 2020 at 03:17:03PM +0100, Martin Marmsoler wrote:
> thanks for your response. Yes I'm looking at refactor+qt5-19 branch. Why do
> you wanna support multiple build systems? But it makes sense to have one
> place where all source and header files are define if multiple build
> systems are needed.

This is a good question.

Well, autotools is complete and working, and others wish to user other
systems. why do you need cmake? I want to be able to say "go for it",
without taking responsibility or maintenanceship of such additional
stuff. there is autotools, plain make, qmake, cmake, meson, waf, scons
(to name a few) and a new creation about every year. Which one is
appropriate? which one isnt? I don't know. People do want to try.

Note that there will probably be a mechanism to build extensions from an
installed Qucs. and it might use neither of the build systems named
above.

> With plugins you mean different features of qucs? So they aren't anymore
> part of the core, but only plugins?

Yes. the initial motivation for plugins are circuit components, and
simulator drivers (including languages). other things follow(ed)
naturally. not sure what you mean by "core". the qucs package will
contain the "core" library implementing the GUI + a bunch of plugins
that implement 0.0.20 "legacy" behaviour, this will be optional, and
pave the way for new ideas.

> For me the structure of qucs is not that clear, in the main folder there is
> a qucs which is the GUI it self?

main/main.cc is the default entry point for the GUI application. it is
in a separate directory in order to reduce complexity and increase
modularity. there is still stuff in main.cc that needs to be folded back
into the library.

> Qucsator is in it's own repository so that
> it can be included or not, to add different solvers?

Qucsator is optional, as is the qucsator driver in qucs. other
simulators are intended. some other drivers will likely be included with
the qucs (gui) repository.

The top level repo will be retained (with qucs qucsator qucs-doc or more
as submodules), to provide a "starting point". this may be irrelevant in
the future, once qucs will be distributed by other means (e.g. as part
of operating systems).

> In the qucs folder I find some "tools" (qucs-attenuator, qucs-filter,
> qucs-powercombining) are they completely standalone so that they can be
> included or not?

I have not touched the tools yet. ideally they will be moved to an
appropriate place, within the qucs package.

> And then in the qucs/qucs folder, the main stuff for the
> GUI is stored.

qucs/qucs will be qucs/lib or qucs/src, at some point. This is meant to
contain only a shared library.

cheers
felix

Re: [Qucs-devel] Project structure

[Martin M. <mar...@gm...>]

Hi Felix,

thanks for your response. Yes I'm looking at refactor+qt5-19 branch. Why do
you wanna support multiple build systems? But it makes sense to have one
place where all source and header files are define if multiple build
systems are needed.
With plugins you mean different features of qucs? So they aren't anymore
part of the core, but only plugins?

For me the structure of qucs is not that clear, in the main folder there is
a qucs which is the GUI it self? Qucsator is in it's own repository so that
it can be included or not, to add different solvers?
In the qucs folder I find some "tools" (qucs-attenuator, qucs-filter,
qucs-powercombining) are they completely standalone so that they can be
included or not? And then in the qucs/qucs folder, the main stuff for the
GUI is stored.

cheers,

Martin



Am Sa., 5. Dez. 2020 um 14:24 Uhr schrieb Felix Salfelder <
fe...@sa...>:

> On Sat, Dec 05, 2020 at 10:01:45AM +0100, Martin Marmsoler wrote:
> > I looked at the qucs project structure and I've seen that in the folder
> > qucs/qucs exists a dialogs folder, but the dialogs it self are directly
> > stored in qucs/qucs. Is there a plan to move these files back to the
> > dialogs folder or is the plan to make a more flat project structure?
> >
> > I'm trying to update the cmake files. Therefore I need this information.
>
> Dear Martin.
>
> Thanks for looking into the CMake files. You are probably looking at the
> refactor+qt5-19 branch.
>
> The relevant move forward is merge request 1007 [1]. It aims at
> splitting up Qucs into library and plugins, supporting arbitrary build
> systems, while keeping the source tree clean. If you are curious, The
> same has been done here [2] in a related project. I think that in Qucs,
> both the autotools build and the cmake build could be part of the main
> repo. We need $toplevel/qucs/autotools and $toplevel/qucs/cmake
> directories for this, and some less sketchy convention/agreement for
> what is supposed to be in the MakeLists.
>
> Dialogs were in qucs/qucs/dialogs, but, as different elements have
> different Dialogs, it does not seem sensible to expose specialised
> dialogs to the global namespace. It seems that the dialogs directory
> will go away, leaving behind only a header (in include?), and all
> dialogs will be implemented (independently) within plugins alongside the
> Element they correspond to. You will find that this is already the case
> for most of them.
>
> Let me know if you have any questions.
>
> regards
> felix
>
> [1] https://github.com/Qucs/qucs/pull/1007
> [2] http://gnucap.org/dokuwiki/doku.php/gnucap:manual:autotools
>

Re: [Qucs-devel] Project structure

[Felix S. <fe...@sa...>]

On Sat, Dec 05, 2020 at 10:01:45AM +0100, Martin Marmsoler wrote:
> I looked at the qucs project structure and I've seen that in the folder
> qucs/qucs exists a dialogs folder, but the dialogs it self are directly
> stored in qucs/qucs. Is there a plan to move these files back to the
> dialogs folder or is the plan to make a more flat project structure?
> 
> I'm trying to update the cmake files. Therefore I need this information.

Dear Martin.

Thanks for looking into the CMake files. You are probably looking at the
refactor+qt5-19 branch.

The relevant move forward is merge request 1007 [1]. It aims at
splitting up Qucs into library and plugins, supporting arbitrary build
systems, while keeping the source tree clean. If you are curious, The
same has been done here [2] in a related project. I think that in Qucs,
both the autotools build and the cmake build could be part of the main
repo. We need $toplevel/qucs/autotools and $toplevel/qucs/cmake
directories for this, and some less sketchy convention/agreement for
what is supposed to be in the MakeLists.

Dialogs were in qucs/qucs/dialogs, but, as different elements have
different Dialogs, it does not seem sensible to expose specialised
dialogs to the global namespace. It seems that the dialogs directory
will go away, leaving behind only a header (in include?), and all
dialogs will be implemented (independently) within plugins alongside the
Element they correspond to. You will find that this is already the case
for most of them.

Let me know if you have any questions.

regards
felix

[1] https://github.com/Qucs/qucs/pull/1007
[2] http://gnucap.org/dokuwiki/doku.php/gnucap:manual:autotools

[Qucs-devel] Project structure

[Martin M. <mar...@gm...>]

Hi,

I looked at the qucs project structure and I've seen that in the folder
qucs/qucs exists a dialogs folder, but the dialogs it self are directly
stored in qucs/qucs. Is there a plan to move these files back to the
dialogs folder or is the plan to make a more flat project structure?

I'm trying to update the cmake files. Therefore I need this information.

Cheers,

Martin

Re: [Qucs-devel] [Feature Request] parallel coupled microstrip lines

[Felix S. <fe...@sa...>]

On Sun, Oct 11, 2020 at 10:07:17AM +0000, Eyerly Dominik wrote:
> In order to implement many microstrip based filters (interdigital,
> hairpin etc), a model that allows a single microstrip line to couple
> to multiple other is needed. ADS solves this by allowing the user to
> select the number of coupled lines and then specify Width1, Space1,
> Width2, Space2, ... etc. Any chance of getting a component like this?

Dear Dominik.

That's a nice project. Could you figure out the model equations that the
commercial tool uses? Or, preferrably, can you reduce multiple lines to
the 2-line case? (I'm not an expert in these things -- maybe somebody
here could give advice.)

I have looked into the qucsator code recently... I recommend to build
one device per port count to get started. More "convenience" in the user
interface could be added later on, but with care, and maybe not in the
Qt3 UI. There is provision for these things in the refactored code.

best regards
felix

Re: [Qucs-devel] Patch for marker.cpp

[Bruno A. C. G. <br...@tr...>]

I sent today three patches:

First, patch in marker.cpp:

diff -ur qucs-0.0.19-orig/qucs/qucs/diagrams/marker.cpp
qucs-0.0.19/qucs/qucs/diagrams/marker.cpp
--- qucs-0.0.19-orig/qucs/qucs/diagrams/marker.cpp      2016-11-22
23:41:48.000000000 +0100
+++ qucs-0.0.19/qucs/qucs/diagrams/marker.cpp   2020-10-24
16:50:08.932744483 +0200
@@ -201,8 +201,6 @@
  pD = pGraph->axis(0);
  if(pGraph->axis(1)) {
    *py = VarPos[1];
-  }else{
-    qDebug() << *py << "is not" << VarPos[1]; // does it really matter?!
  }

  double pz[2];

Second, qucsator core dumped with modern versions of C++.  It seems that it
"reserve" space for elements in an array, but didn't resize the array,
after that it access non-existent elements, simple patch:

diff -ur qucs-0.0.19-orig/qucs-core/src/nodelist.cpp
qucs-0.0.19/qucs-core/src/nodelist.cpp
--- qucs-0.0.19-orig/qucs-core/src/nodelist.cpp 2016-11-22
23:41:48.000000000 +0100
+++ qucs-0.0.19/qucs-core/src/nodelist.cpp      2020-10-24
16:45:40.400141625 +0200
@@ -152,7 +152,7 @@

  // create fast array access possibility
  narray.clear();
-  narray.reserve(this->length());
+  narray.resize(this->length());

  for (auto n: root) {
    // ground node gets a zero counter

And the last:  When I rotate an ac current source it's impossible to
connect a wire to the terminals.  It seems that the terminals were left
unaligned with the grid.  The following patch seems to fix the problem, but
someone with knowledge about the code must review it:

diff -ur qucs-0.0.19-orig/qucs/qucs/components/ampere_ac.cpp
qucs-0.0.19/qucs/qucs/components/ampere_ac.cpp
--- qucs-0.0.19-orig/qucs/qucs/components/ampere_ac.cpp 2016-11-22
19:40:33.000000000 +0100
+++ qucs-0.0.19/qucs/qucs/components/ampere_ac.cpp      2020-10-24
23:45:01.817499844 +0200
@@ -34,7 +34,7 @@
  Ports.append(new Port( 30,  0));
  Ports.append(new Port(-30,  0));

-  x1 = -30; y1 = -14;
+  x1 = -30; y1 = -16;
  x2 =  30; y2 =  16;

  tx = x1+4;

Regards,

Bruno


El mar., 10 nov. 2020 a las 16:32, Felix Salfelder (<fe...@sa...>)
escribió:

> On Tue, Nov 10, 2020 at 03:53:30PM +0100, Bruno Alberto Crespo García
> wrote:
> > This little patch fixes the problem.
>
> thanks for your contribution. (and for avoiding the git workflow
> madness).
>
> but the mailing list strips off your attachments, maybe you can embed
> the patch into your email...
>
> cheers
> felix
>

Re: [Qucs-devel] Patch for marker.cpp

[Felix S. <fe...@sa...>]

On Tue, Nov 10, 2020 at 03:53:30PM +0100, Bruno Alberto Crespo García wrote:
> This little patch fixes the problem.

thanks for your contribution. (and for avoiding the git workflow
madness).

but the mailing list strips off your attachments, maybe you can embed
the patch into your email...

cheers
felix

[Qucs-devel] Core dump in qucsator

[Bruno A. C. G. <br...@tr...>]

Hello,

It seems that qucsator core-dumps on Fedora 32 and 33.  This patch fixes it.

The code in nodelist.cpp reserve space in an array, but it didn't change
the size, after that it accessed non-existent elements, and this is
undefined behaviour on C++.

This small patch fixes the problem.

Bruno