You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(12) |
Feb
(9) |
Mar
(2) |
Apr
(9) |
May
(15) |
Jun
(2) |
Jul
|
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(4) |
Dec
|
2005 |
Jan
(3) |
Feb
(11) |
Mar
(9) |
Apr
(26) |
May
(10) |
Jun
(1) |
Jul
(10) |
Aug
(2) |
Sep
(8) |
Oct
(15) |
Nov
(8) |
Dec
(15) |
2006 |
Jan
(53) |
Feb
(21) |
Mar
(26) |
Apr
(20) |
May
(30) |
Jun
(22) |
Jul
(24) |
Aug
(36) |
Sep
(61) |
Oct
(21) |
Nov
(7) |
Dec
(8) |
2007 |
Jan
(30) |
Feb
(43) |
Mar
(40) |
Apr
(59) |
May
(8) |
Jun
(19) |
Jul
(34) |
Aug
(35) |
Sep
(9) |
Oct
(9) |
Nov
(66) |
Dec
(36) |
2008 |
Jan
(22) |
Feb
(42) |
Mar
(19) |
Apr
(25) |
May
(36) |
Jun
(16) |
Jul
(31) |
Aug
(16) |
Sep
(27) |
Oct
(25) |
Nov
(36) |
Dec
(24) |
2009 |
Jan
(38) |
Feb
(20) |
Mar
(62) |
Apr
(81) |
May
(53) |
Jun
(5) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(9) |
Nov
(8) |
Dec
(5) |
2010 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(10) |
2011 |
Jan
(4) |
Feb
(6) |
Mar
(29) |
Apr
(19) |
May
(4) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(3) |
Nov
(13) |
Dec
(3) |
2012 |
Jan
(2) |
Feb
(3) |
Mar
(3) |
Apr
(1) |
May
(7) |
Jun
(3) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
(6) |
Dec
(4) |
2013 |
Jan
(41) |
Feb
(8) |
Mar
(14) |
Apr
(15) |
May
(15) |
Jun
(95) |
Jul
(91) |
Aug
(20) |
Sep
(19) |
Oct
(47) |
Nov
(29) |
Dec
(55) |
2014 |
Jan
(56) |
Feb
(7) |
Mar
(16) |
Apr
(14) |
May
(3) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(4) |
Oct
(10) |
Nov
(35) |
Dec
(51) |
2015 |
Jan
(31) |
Feb
(28) |
Mar
(4) |
Apr
(31) |
May
(6) |
Jun
(23) |
Jul
(16) |
Aug
(2) |
Sep
(10) |
Oct
(9) |
Nov
(3) |
Dec
(6) |
2016 |
Jan
(14) |
Feb
(8) |
Mar
(11) |
Apr
(7) |
May
(1) |
Jun
(6) |
Jul
(5) |
Aug
(6) |
Sep
(3) |
Oct
(10) |
Nov
(12) |
Dec
(14) |
2017 |
Jan
(13) |
Feb
(8) |
Mar
(14) |
Apr
(26) |
May
(37) |
Jun
(15) |
Jul
(15) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(4) |
Dec
|
2018 |
Jan
(26) |
Feb
(7) |
Mar
(1) |
Apr
(3) |
May
(18) |
Jun
(5) |
Jul
(34) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(4) |
Dec
|
2019 |
Jan
(15) |
Feb
(2) |
Mar
(5) |
Apr
(5) |
May
(1) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(3) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
2020 |
Jan
(4) |
Feb
(3) |
Mar
(2) |
Apr
(26) |
May
|
Jun
(1) |
Jul
(9) |
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(7) |
Dec
(11) |
2021 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(6) |
2022 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2023 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2024 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Felix S. <fe...@sa...> - 2019-03-16 09:51:50
|
On Wed, Mar 13, 2019 at 10:50:41PM +0100, Guilherme Brondani Torri wrote: > > 4) Naming of the wires could be automatic so that the user do need to > > worry > > about it. That would change a pit the annotation > > of observable nodes for the simulation. > > I guess you mean nets or nodes, not each wire as drawn on the > schematic. Yes it makes sense to have a unique identifier for them. > I believe that right now connectivity is checked by overlapping ports > and ends of wires. So, a better representation is needed to capture > what is connected to each node. Something that makes it easy to > traverse the hypergraph that the schematic represents. I see what you are getting into now. I agree, there are some changes required. Actually, Qucs explicitly keeps track of connectivity between ports (of components and at ends of wires). This is big plus. What it does not do (yet) is keeping track of connected components of wires (aka "nets" in the qucsator netlists). In my rework, I have isolated and refactored the code for recomputing those connected components. there is a hack in the netlisters that triggers it. It must be done dynamically instead (see [1]). With this, the UI could expose/visualise/highlight/label the nets to the user in a consistent way. it has to do with user interactions, and some actions will have to trigger the update... this is in flux, getting rid of the netlist hook -- without breaking the netlisters -- is the first step. cheers felix [1] https://en.wikipedia.org/wiki/Dynamic_connectivity |
From: Guilherme B. T. <gui...@gm...> - 2019-03-13 21:51:19
|
Hello Jouko, Let me add to Felix comments. On Mon, Mar 4, 2019 at 10:20 AM <jou...@wi...> wrote: > Hello Guilherme Brondani Torri > > > <snip> > > What I like to change at most in the Qucs are: > 0) The publishing rate should slow down or halted till all fundamental > flaws are > corrected BECAUSE: several features of the Qucs are done at the same > time and unless > the fundamental flaws are corrected, they are inherited to next > versions. > You mean release rate or merge rate? If you mean the releases I disagree to some extent. People put a lot of effort to make new features unaware of the flaws. I felt it was silly to not release them while the fixes for the fundamental flaws are not yet worked out. We certainly need to make some deep restructuring, and in this case a feature freeze is recommended not to waste developer's time. 1) The policy of drawing wires. If you insists that the present policy > should > be preserved, it is possible in Qt to include several > drawing policies into the program and let the user choose the one > he prefers. I am working with this issue at the moment. > The user interaction will be mostly refactored with the adoption of Qt5. If you are working on it, most likely it will be rewritten in Qt5. > 2) the way Qucs display results. My version of Qucs (0.18), the user > cannot do any measurements, > zoom, or transformation in the graph. > IMHO the diagrams are nice and simple. To have more inteligent diagrams significant work must be done. It is worth investigating if we are not better off by replacing the diagrams by 3rd party libraries, such as QwtPlot... > 3) Schematics and the simulation > results. Either as graphs or as tables, should be on a separate Tab. > Qt v4.0 > even offer a widget for table, which could be utilised instead of the > present > way to list the simulation data. > > I don't follow you. > 4) Naming of the wires could be automatic so that the user do need to > worry > about it. That would change a pit the annotation > of observable nodes for the simulation. > I guess you mean nets or nodes, not each wire as drawn on the schematic. Yes it makes sense to have a unique identifier for them. I believe that right now connectivity is checked by overlapping ports and ends of wires. So, a better representation is needed to capture what is connected to each node. Something that makes it easy to traverse the hypergraph that the schematic represents. > 5) Spice should be one of the netlist formats the Qucs can understand. > That > is already done to some extend with the S-Qucs project. > Note that since forever the native simulator engine was only Qucsator. It does not speak Spice, but rather a dialect similar to ADS. A netlist translator tool, qucsconv, was used to bridge the languages. Felix is writing a GnuCap wrapper that can also undestand the Qucs netlist. However the RF components are not available in GnuCap. More recently Qucs-S forqued and started using ngspice/xyce as engine. Components available for Qucsator are not available in ngspice/xyce (and vice-versa). If you see in Qucs-S, there are symbols with different colors (or in different libraries) in to indicate the supported simulation engine. This can get really messy really quickly, specially with new users. This is why Qucs-S forked and not yet merged back. It is not only about what is the output netlit format, but also how to allow users to manage different simulators. This relates on how the component libraries are build and how the instances are netlisted (to one ore more target simulators). We need more infrastructure to support multiple simulators and file formats. 6) virtual memory system, provided by the any modern OS, should be > utilized > in netlists, matrix solution math and simulations etc. to accomplish > longer and > larger simulations. > If you are talking about Qucsator, yes. It is not very fast/modern. But given that it was mostly written by one or two part-time developers, I think it is quite an achievement. Perhaps it is best left alone and its functionalities (mainly the RF components and analyses) should be ported to other engines which are designed to scale to larger circuits (xyce, gnucap, ngspice). > 7) Because English is a true world's language, and despite the Qt offer > very > handy and working means to translate GUI to various languages, the > various > translations of Qucs should not have very high priority. > > I disagree. Translation can be done by non-technical volunteers. See our Transifex site. It is very little burden to maintain and it helps attracting non-English speakers. Now, providing support for translation at schematic level (the document) is something I am not so sure. > And next some questions: > > Does any of you, in the development team, have access to either Mentor > or > Cadence tools? > I have used many tools... > How does the development cycle works in practice? Should the documented > new versions of the program to be sent to you, the development team, to > be > estimated and commented before they are included to the official > version, or > what and how? > > We try to tag relevant features as milestones on GitHub. When most things are merged/fixed we try to release. If you want to propose changes file issues on GitHub or make pull requests. If more input is need, try the mailing list. > Do you have assigned person to steer the project? > > We have about 4 active maintainers (me, felix, in3odt, andresmeras). I did most (all?) releases after Frans stopped his activity. I try to speak for the project whenever possible. But I am was not assigned by anyone and currently I have very little time to dedicate to it. > How to get information on what features of the program are under > development > at the moment, and who are working with them? > > GitHub, somethings the mailing list. > > I have downloaded both the first public version (v0.1) and version 0.18 > of the program. Both versions can be compiled in my system and they > works > fine. At the moment I try to study and understand the program structure, > and > my first aim, as was mentioned, is to improve the wire editing features. > > My aim is to use the drawing policy which draw Wire only in the place > where > the user wants them to appear (i.e. no optimization). I also try to > include dynamic wire drawing, > editing, coping etc. and dynamic component placement editing features > to > the program i.e. when user wants to move a wire or a component, he/she > can > SEE it moving with the cursor. > > As mentioned. I would not do it now. Qt5 migration will likely undo most of you work... > It would be nice if I could contribute something for the project. But > before > you add me name to the list of the honoured developers :-), please tell > me your > attitude about the development ideas and the direction of the > development, and > also I'd like to read your reply on the questions I asked. > > There are some easy-fixes tagged on GitHub. The top priority is to finish the Qt5 port. There is some work done by me and by felix, perhaps we are pulling in different directions at the moment. If you wan to help let us know and we can discuss further. Regards, Guilherme |
From: Felix S. <fe...@sa...> - 2019-03-04 10:44:10
|
Dear Jouko. Thanks for your interest in contributing to Qucs. let me try and answer some of your questions. > > 1) The policy of drawing wires. If you insists that the present policy > > should > > be preserved, it is possible in Qt to include several > > drawing policies into the program and let the user choose the one > > he prefers. I am working with this issue at the moment. this sounds promising. please think carefully about how the selection of policies will be presented and implemented. one way to provide alternatives is through types. this is what we will do in future Qucs (the GUI). those types are inherited classes with a custom implementation contained in an (optional) plugin. > > 2) the way Qucs display results. > > 3) Schematics and the simulation > > 4) Naming of the wires could be automatic so that the user do need to > > 5) Spice should be one of the netlist formats the Qucs can understand. these also need to come as plugins, some progress is on the way. > > 6) virtual memory system, provided by the any modern OS, should be I don't fully understand. Perhaps what you are saying that there should be a (more sensible) layer between a simulator and the GUI. i call it simulator "drivers". these will be plugins, and may compete with each other in terms of proper memory and operating system use. > > 7) Because English is a true world's language, and despite the Qt > > [..] > > translations of Qucs should not have very high priority. everyone is allowed to set her/his own priorities. (I do not care about translations myself, but it is not hard to review changes in this area). > > How does the development cycle works in practice? Should the documented > > new versions of the program to be sent to you, the development team, > > to be estimated and commented before they are included to the official > > version, or what and how? We use git to keep track of additions/changes. review and integration is done through a web discussion forum kind of thing. it is partly automated. currently the project is hosted on github, which is no longer considered a suitable platform for free sotware development. should be fixed, but it is not a requirement right now. > > My aim is to use the drawing policy which draw Wire only in the place > > where the user wants them to appear (i.e. no optimization). I also try to > > include dynamic wire drawing, > > editing, coping etc. and dynamic component placement editing features to > > the program i.e. when user wants to move a wire or a component, he/she > > can SEE it moving with the cursor. if you manage to turn these policies into types, then everybody could have his own favourite. there are too many ways to do it, and too many detailed opinions. one of them is not to change the current (default) behaviour. note that some of the wiring has to be refactored in order to make it work with Qt5. We have declared Qt5 support a priority out of necessity, but it gets difficult very quickly. cheers felix |
From: Frans S. <fra...@gm...> - 2019-03-04 08:47:09
|
Dear Jouko Marjonen, Thanks for the long email and offer to help. I personally am not so active anymore, so I would ask you to direct your email to the developers list of qucs instead of me personally. quc...@li... You may have to subscribe to the list first in order to send messages. Kind regards, Frans Schreuder On 04-03-19 08:45, jou...@wi... wrote: > Hello Frans Schreuder, > > I have been following your Qucs project and I think that it have some > potential. > > Personally, I have over ten years experiencing of analogue-mixed/RF > mode full custom > ASIC design, thus, I have my own preference on how various design > tools should feel and look. > > I have used both the Mentor suite tools and Cadence suite tools. > > I appreciate your effort in this project, because there is absolutely NO > FREE, HANDY, FULLY WORKING (or at least to some extend working) etc. > electronics design tool on the open source > market. Instead, all are BUGGY, LOW MEMORY, GLUMSY etc. attempt to > fill the > need. > > Qucs can be the one (of those in FREE etc. kind :-)), but I think that > that is > still quite far, or there is need for significant changes in the > program to reach the goal. > > I have been in contact to Frans Schreuder, and He told me that he is > no longer so active > in the development. > > What I like to change at most in the Qucs are: > 0) The publishing rate should slow down or halted till all fundamental > flaws are > corrected BECAUSE: several features of the Qucs are done at the same > time and unless > the fundamental flaws are corrected, they are inherited to next versions. > > 1) The policy of drawing wires. If you insists that the present policy > should > be preserved, it is possible in Qt to include several > drawing policies into the program and let the user choose the one > he prefers. I am working with this issue at the moment. > > 2) the way Qucs display results. My version of Qucs (0.18), the user > cannot do any measurements, > zoom, or transformation in the graph. > > 3) Schematics and the simulation > results. Either as graphs or as tables, should be on a separate Tab. > Qt v4.0 > even offer a widget for table, which could be utilised instead of the > present > way to list the simulation data. > > 4) Naming of the wires could be automatic so that the user do need to > worry > about it. That would change a pit the annotation > of observable nodes for the simulation. > > 5) Spice should be one of the netlist formats the Qucs can understand. > That > is already done to some extend with the S-Qucs project. > > 6) virtual memory system, provided by the any modern OS, should be > utilized > in netlists, matrix solution math and simulations etc. to accomplish > longer and > larger simulations. > > 7) Because English is a true world's language, and despite the Qt > offer very > handy and working means to translate GUI to various languages, the > various > translations of Qucs should not have very high priority. > > And next some questions: > > Does any of you, in the development team, have access to either Mentor or > Cadence tools? > > How does the development cycle works in practice? Should the documented > new versions of the program to be sent to you, the development team, > to be > estimated and commented before they are included to the official > version, or > what and how? > > Do you have assigned person to steer the project? > > How to get information on what features of the program are under > development > at the moment, and who are working with them? > > > I have downloaded both the first public version (v0.1) and version 0.18 > of the program. Both versions can be compiled in my system and they works > fine. At the moment I try to study and understand the program > structure, and > my first aim, as was mentioned, is to improve the wire editing features. > > My aim is to use the drawing policy which draw Wire only in the place > where > the user wants them to appear (i.e. no optimization). I also try to > include dynamic wire drawing, > editing, coping etc. and dynamic component placement editing features to > the program i.e. when user wants to move a wire or a component, he/she > can > SEE it moving with the cursor. > > It would be nice if I could contribute something for the project. But > before > you add me name to the list of the honoured developers :-), please > tell me your > attitude about the development ideas and the direction of the > development, and > also I'd like to read your reply on the questions I asked. > > With all respect and regards, Jouko Marjonen > > > > |
From: Ricardo <ric...@gm...> - 2019-02-28 22:33:11
|
Hello, russelsh2. Yes, you can use qucs to simulate commercial products. You can also plot some data or create a schematic, generate an image from it and put in a close documentation. Your only limitation is to modify qucs source code it self, in this case you should release the new code in GPL. You cannot put qucs source code in a proprietary software. The complete license can be found in: https://github.com/Qucs/qucs/blob/develop/qucs-core/COPYING If you have a more precise question we can try our best to answer it. Bye, Ricardo. 2019-02-28 17:35 GMT-03:00, russellsh2 via Qucs-devel <quc...@li...>: > Can Qucs be used for commercial use > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: russellsh2 <rus...@ya...> - 2019-02-28 20:35:55
|
Can Qucs be used for commercial use |
From: Felix S. <fe...@sa...> - 2019-01-25 22:18:15
|
On Thu, Jan 24, 2019 at 09:32:48PM +0100, Guilherme Brondani Torri wrote: > I just uploaded the qucsator-0.0.20-rc1 source tarball to: > https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ there are binaries in the tarball, such as ._TODO. it looks like by accident. is this the result of "make dist"? but more tricky, the package builds and installs a public library, libqucsator. the version is at 0.0.0. this will not work in Debian. it might be better to not expose it, but to install it into $pkglibdir, and drop the version, if it has no meaning. how is this library used, other than in qucsator? thanks felix |
From: Felix S. <fe...@sa...> - 2019-01-25 00:11:01
|
On Thu, Jan 24, 2019 at 09:32:48PM +0100, Guilherme Brondani Torri wrote: > I just uploaded the qucsator-0.0.20-rc1 source tarball to: > https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ Thanks Guilherme I have uploaded a stub, here [1]. it produces a binary package to get started. More work is needed, before it will be accepted. Might as well inform -rc2. My plan is to transfer it to the electronics team [2] once ready and I have a sponsor. Not sure about when. Please don't hesitate to take it. cheers [1] https://salsa.debian.org/felixs-guest/qucsator [2] https://salsa.debian.org/electronics-team/ |
From: Guilherme B. T. <gui...@gm...> - 2019-01-24 20:33:09
|
Hello Felix, I just uploaded the qucsator-0.0.20-rc1 source tarball to: https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ Regards, Guilherme On Wed, Jan 23, 2019 at 10:08 AM Felix Salfelder <fe...@sa...> wrote: > Hi Guilherme. > > On Tue, Jan 22, 2019 at 11:11:31PM +0100, Guilherme Brondani Torri wrote: > > I suppose telling the Debian packager to only consider stuff inside > > qucs-core/ is not good enough. > > possible, but will make things more difficult and duplicate work. > packages (including source packages) are reviewed thoroughly in Debian. > smaller and straightforward packages are less work and take fewer > iterations. > > > - qucs-[all sources, as done up to now] > > - qucs-[ui applications] > > - qucsator > > - qucs-doc > > that's what I had in mind. qucs-test is another one, but already there. > i have played with git submodules and git-filter-branch. I am surprised > how well it works these days. (this is nowhere near urgent, lets do > qucsator some day and see). > > > If it helps to get things going I can make and upload already a > > qucsator-0.0.20-rc1 source package. > > thank you! > felix > |
From: Felix S. <fe...@sa...> - 2019-01-24 10:40:39
|
On Sun, Jan 20, 2019 at 05:28:52PM +0100, ripudaman khattar wrote: > *Hello team,* > My name is Ripudaman and currently studying analog electronics. > Would it be possible to work with you on analog, digital circuits and some > task that you had mentioned in specific todo items? I have both Windows and > Linux systems Dear Ripudaman. If you are also interested in implementation and programming, we could need any help with the Qt5 transition... Please let us know what tools and languages you are familiar with. cheers felix |
From: Felix S. <fe...@sa...> - 2019-01-23 09:08:20
|
Hi Guilherme. On Tue, Jan 22, 2019 at 11:11:31PM +0100, Guilherme Brondani Torri wrote: > I suppose telling the Debian packager to only consider stuff inside > qucs-core/ is not good enough. possible, but will make things more difficult and duplicate work. packages (including source packages) are reviewed thoroughly in Debian. smaller and straightforward packages are less work and take fewer iterations. > - qucs-[all sources, as done up to now] > - qucs-[ui applications] > - qucsator > - qucs-doc that's what I had in mind. qucs-test is another one, but already there. i have played with git submodules and git-filter-branch. I am surprised how well it works these days. (this is nowhere near urgent, lets do qucsator some day and see). > If it helps to get things going I can make and upload already a > qucsator-0.0.20-rc1 source package. thank you! felix |
From: Cheng F. P. <fei...@ho...> - 2019-01-23 05:09:01
|
Hi, > http://qucs.sourceforge.net/docs.html > The documentation is much more mature than the implementation. It's a > matter of priorities. > you could use gnucap-adms in combination with gnucsator for the opposite > experience. phung@UbuntuHW15:~/Documents/phung/Analog/BSIM-BULK_106.2.0_20170630/code$ sudo updatedb phung@UbuntuHW15:~/Documents/phung/Analog/BSIM-BULK_106.2.0_20170630/code$ sudo locate -b "libgnucap.so" /home/phung/Downloads/gnucap/lib/O/libgnucap.so /usr/local/lib/libgnucap.so phung@UbuntuHW15:~/Documents/phung/Analog/BSIM-BULK_106.2.0_20170630/code$ gnucap -a lang_adms.so -a d_adms_vbr.so -a d_adms_i.so -a c_make_attach.so gnucap: error while loading shared libraries: libgnucap.so: cannot open shared object file: No such file or directory phung@UbuntuHW15:~/Documents/phung/Analog/BSIM-BULK_106.2.0_20170630/code$ Could anyone help ? thanks Phung |
From: Guilherme B. T. <gui...@gm...> - 2019-01-22 22:11:50
|
Hello, I probably missed the news that ADMS was now on Debian. It would be nice to add the install instructions to the Readme. I suppose telling the Debian packager to only consider stuff inside qucs-core/ is not good enough. Besides the confusion it might create, I don't see a problem releasing multiple source tarballs. For consistency, down the road it might make sense to have either 4 or 3 source tarballs. A better naming convention is needed Source packages: - qucs-[all sources, as done up to now] - qucs-[ui applications] - qucsator - qucs-doc Qt5 transition will be sorted out eventually... qucs-doc should also be free and can be painful to build. It would be nice to have it packaged as well. If it helps to get things going I can make and upload already a qucsator-0.0.20-rc1 source package. Regards, Guilherme |
From: Ricardo <ric...@gm...> - 2019-01-20 19:31:15
|
Hello, I'm not one of the core developers, but I suggest you to look at https://github.com/Qucs/qucs/issues . There are some issues that are marked with easy-fix . There are some other qucs related projects in https://github.com/Qucs/ , there are some issues in qucs-help that look very easy. Good luck, Ricardo. 2019-01-20 14:28 GMT-02:00, ripudaman khattar <rip...@gm...>: > *Hello team,* > My name is Ripudaman and currently studying analog electronics. > Would it be possible to work with you on analog, digital circuits and some > task that you had mentioned in specific todo items? I have both Windows and > Linux systems > > I will be waiting for your reply. > > thanking you in advance > > Best regards > Ripudaman > ᐧ > > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: ripudaman k. <rip...@gm...> - 2019-01-20 17:29:12
|
*Hello team,* My name is Ripudaman and currently studying analog electronics. Would it be possible to work with you on analog, digital circuits and some task that you had mentioned in specific todo items? I have both Windows and Linux systems I will be waiting for your reply. thanking you in advance Best regards Ripudaman ᐧ |
From: Claudio G. <cla...@vi...> - 2019-01-17 20:25:49
|
Hello, these links point to the latest Qucs binary packages for Windows, automatically built by AppVeyor from the master branch: - 64-bit version: https://ci.appveyor.com/api/projects/qucs/qucs/artifacts/qucs-win64.zip?branch=master&job=Environment%3A%20MSYSTEM%3DMINGW64%2C%20MBITS%3D64%2C%20MARCH%3Dx86_64 https://ci.appveyor.com/api/projects/qucs/qucs/artifacts/qucs-win64.zip?branch=master&job=Environment%3A%20MSYSTEM%3DMINGW64%2C%20MBITS%3D64%2C%20MARCH%3Dx86_64 - 32-bit version: https://ci.appveyor.com/api/projects/qucs/qucs/artifacts/qucs-win32.zip?branch=master&job=Environment%3A%20MSYSTEM%3DMINGW32%2C%20MBITS%3D32%2C%20MARCH%3DI686 https://ci.appveyor.com/api/projects/qucs/qucs/artifacts/qucs-win32.zip?branch=master&job=Environment%3A%20MSYSTEM%3DMINGW32%2C%20MBITS%3D32%2C%20MARCH%3DI686 so they currently contain the binaries for the 0.0.20 release candidate. Regards, Claudio > > Il 17 gennaio 2019 alle 11.36 Derek Kozel <de...@bi...> ha scritto: > > Hello Guilherme, > > Congrats on reaching this milestone! I've tried a few of my projects on > the RC and they're working well on Ubuntu. Is it possible to get an > installer built for Windows? I don't have the development environment > setup there but would happily test a binary version. > > Thanks! > Derek > > On 13/01/2019 12:37, Guilherme Brondani Torri wrote: > > > > > > Hello, > > > > The 'qucs-0.0.20-rc1' version is merged and tagged on the 'master' branch. > > The configured tarball is available at: > > https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ > > > > Test and feedback is welcome. > > > > Regards, > > Guilherme > > > > _______________________________________________ > > Qucs-devel mailing list > > Quc...@li... > > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > > > > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Felix S. <fe...@sa...> - 2019-01-17 16:43:13
|
On Thu, Jan 17, 2019 at 02:48:00PM +0100, Wladek Grabinski wrote: > just last week I have asked Guilherme a similar question about Qucs > binaries for Linux. I am not sure how create a test environment for all the > different Qucs binaries compilation and testing. Maybe coming FOSDEM Dear all. Usually, binary packages are distributed by the various GNU/Linux distributions. While everyone is natuarally entitled to create their own binaries and share them with whoever, the sucess and impact is usually limited. I suggest to do what other developers do. Kindly adress people that are more proficient in this area. In Debian, we do now have an adms package, alleviating the qucsator build process. for a long time, adms was the reason why QUCS was not part of official Debian repositories. (adms was not free software until recently, and qucsator was deemed a hard dependency). We should take the opportunity to get qucsator into Debian, to further simplify the process of obtaining a usable QUCS 0.0.20. On that end, an official qucsator-0.0.20 tarball with or without -rc1 is crucial. With qucsator in place, users could at least build, run and use their own qucs (the gui) binaries with no need to dig through all and more tedious dependencies or installation process. (and other useful things.) The obvious goal is to have all of it packaged. The reason why the gui is not in Debian today, is the Qt3support dependency. Qt3 and Qt4 have been phased out, and packages depending on these will be or have been removed, see [1]. The situation is similar or the same in other distros. The transition to Qt5 is currently being worked on. With the Qt4 dependency dropped, the issue will be completely resolved. > CAD/EDA DevRoom > <https://fosdem.org/2019/schedule/track/cad_and_open_hardware/> (Feb. > 2-3, 2019) > would be a right place to address all these questions? Sure. Perhaps we should also address the realities of the Qt5 transition. regards felix [1] https://wiki.debian.org/Qt4Removal |
From: Derek K. <de...@bi...> - 2019-01-17 16:26:03
|
Hi Feliz and Wladek, I'll be in the devroom at FOSDEM and would be interested in talking about packaging. I'm only getting started maintaining packages (packaging linux-gpib), but have some experience of the process from working on GNU Radio. Having good maintainers for each OS is difficult, but I agree really the only way to make binary distribution successful in the long run. Derek On 17/01/2019 16:09, Felix Salfelder wrote: > On Thu, Jan 17, 2019 at 02:48:00PM +0100, Wladek Grabinski wrote: >> just last week I have asked Guilherme a similar question about Qucs >> binaries for Linux. I am not sure how create a test environment for all the >> different Qucs binaries compilation and testing. Maybe coming FOSDEM > Dear all. > > Usually, binary packages are distributed by the various GNU/Linux > distributions. While everyone is natuarally entitled to create their own > binaries and share them with whoever, the sucess and impact is usually > limited. I suggest to do what other developers do. Kindly adress people > that are more proficient in this area. > > In Debian, we do now have an adms package, alleviating the qucsator > build process. for a long time, adms was the reason why QUCS was not > part of official Debian repositories. (adms was not free software until > recently, and qucsator was deemed a hard dependency). We should take the > opportunity to get qucsator into Debian, to further simplify the process > of obtaining a usable QUCS 0.0.20. On that end, an official > qucsator-0.0.20 tarball with or without -rc1 is crucial. > > With qucsator in place, users could at least build, run and use their > own qucs (the gui) binaries with no need to dig through all and more > tedious dependencies or installation process. (and other useful things.) > > The obvious goal is to have all of it packaged. The reason why the gui > is not in Debian today, is the Qt3support dependency. Qt3 and Qt4 have > been phased out, and packages depending on these will be or have been > removed, see [1]. The situation is similar or the same in other distros. > > The transition to Qt5 is currently being worked on. With the Qt4 > dependency dropped, the issue will be completely resolved. > >> CAD/EDA DevRoom >> <https://fosdem.org/2019/schedule/track/cad_and_open_hardware/> (Feb. >> 2-3, 2019) >> would be a right place to address all these questions? > Sure. Perhaps we should also address the realities of the Qt5 > transition. > > regards > felix > > [1] https://wiki.debian.org/Qt4Removal |
From: Wladek G. <wl...@gr...> - 2019-01-17 14:17:32
|
Hello Derek, just last week I have asked Guilherme a similar question about Qucs binaries for Linux. I am not sure how create a test environment for all the different Qucs binaries compilation and testing. Maybe coming FOSDEM CAD/EDA DevRoom <https://fosdem.org/2019/schedule/track/cad_and_open_hardware/> (Feb. 2-3, 2019) would be a right place to address all these questions? -- thanks -- wladek; On Thu, Jan 17, 2019 at 11:53 AM Derek Kozel <de...@bi...> wrote: > Hello Guilherme, > > Congrats on reaching this milestone! I've tried a few of my projects on > the RC and they're working well on Ubuntu. Is it possible to get an > installer built for Windows? I don't have the development environment > setup there but would happily test a binary version. > > Thanks! > Derek > > On 13/01/2019 12:37, Guilherme Brondani Torri wrote: > > Hello, > > > > The 'qucs-0.0.20-rc1' version is merged and tagged on the 'master' > branch. > > The configured tarball is available at: > > https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ > > > > Test and feedback is welcome. > > > > Regards, > > Guilherme > > > > _______________________________________________ > > Qucs-devel mailing list > > Quc...@li... > > https://lists.sourceforge.net/lists/listinfo/qucs-devel > > > > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Derek K. <de...@bi...> - 2019-01-17 10:53:03
|
Hello Guilherme, Congrats on reaching this milestone! I've tried a few of my projects on the RC and they're working well on Ubuntu. Is it possible to get an installer built for Windows? I don't have the development environment setup there but would happily test a binary version. Thanks! Derek On 13/01/2019 12:37, Guilherme Brondani Torri wrote: > Hello, > > The 'qucs-0.0.20-rc1' version is merged and tagged on the 'master' branch. > The configured tarball is available at: > https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ > > Test and feedback is welcome. > > Regards, > Guilherme > > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Guilherme B. T. <gui...@gm...> - 2019-01-13 12:37:31
|
Hello, The 'qucs-0.0.20-rc1' version is merged and tagged on the 'master' branch. The configured tarball is available at: https://sourceforge.net/projects/qucs/files/qucs/0.0.20/ Test and feedback is welcome. Regards, Guilherme |
From: Guilherme B. T. <gui...@gm...> - 2018-11-20 14:33:36
|
Hello, Is there anybody interested in giving a talk at FOSDEM? The deadline for submission is in two weeks (Dec. 8th). I will probably not be there this time. Regards, Guilherme |
From: Attila K. <at...@ki...> - 2018-11-03 14:02:16
|
On Sat, 3 Nov 2018 12:26:45 +0100 Felix Salfelder <fe...@sa...> wrote: > in fact, there is a qt-name switch in configure. it selects which > pkgconfig files are used. > > $ ./configure --help |grep qt > --with-qt-name Use a specific Qt for building. [default=Qt] > > passing --with-qt-name=Qt5 will select the other version. > > just in case: i don't know how to do this properly, and it might change. > have a look at .travis.xml, if the above is no longer there. That got me further! Thanks. Though, the config error messages have to be slightly improved, I guess. I got --- checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for QTest... yes checking for QT... no configure: error: pkgconfig did not work, see config.log configure: error: ./configure failed for qucs --- Where the cause were missing qtscript5-dev and libqt5svg5-dev packages. from qucs/config.log: --- configure:18086: checking for QT configure:18093: $PKG_CONFIG --exists --print-errors "${qt_name}Core ${qt_name}G ui ${qt_name}Script ${qt_name}Svg ${qt_name}Xml" Package Qt5Script was not found in the pkg-config search path. Perhaps you should add the directory containing `Qt5Script.pc' to the PKG_CONFIG_PATH environment variable No package 'Qt5Script' found Package Qt5Svg was not found in the pkg-config search path. Perhaps you should add the directory containing `Qt5Svg.pc' to the PKG_CONFIG_PATH environment variable No package 'Qt5Svg' found configure:18096: $? = 1 configure:18110: $PKG_CONFIG --exists --print-errors "${qt_name}Core ${qt_name}G ui ${qt_name}Script ${qt_name}Svg ${qt_name}Xml" Package Qt5Script was not found in the pkg-config search path. Perhaps you should add the directory containing `Qt5Script.pc' to the PKG_CONFIG_PATH environment variable No package 'Qt5Script' found Package Qt5Svg was not found in the pkg-config search path. Perhaps you should add the directory containing `Qt5Svg.pc' to the PKG_CONFIG_PATH environment variable No package 'Qt5Svg' found configure:18113: $? = 1 configure:18127: result: no No package 'Qt5Script' found No package 'Qt5Svg' found --- Other than that, it compiles fine. Attila Kinali -- <JaberWorky> The bad part of Zurich is where the degenerates throw DARK chocolate at you. |
From: Felix S. <fe...@sa...> - 2018-11-03 11:48:51
|
On Sat, Nov 03, 2018 at 11:42:39AM +0100, Attila Kinali wrote: > On Sun, 2 Sep 2018 18:19:44 +0200 > Felix Salfelder <fe...@sa...> wrote: > > > I made some progress on the qt5 port, started a develop+qt5 branch [1]. > > it's now at revision 5, develop+qt5-5. it's all based on develop (not > > forking). > > I wanted to give the qt5 port a try, but it still builds against qt4. > I checked out the develop+qt5-6 branch and looked for any switch > I might have forgotten, but couldn't find anything. Is there a > magic incantation I have to use, or is it something else I am missing? Moin Attila. thanks for considering this. in fact, there is a qt-name switch in configure. it selects which pkgconfig files are used. $ ./configure --help |grep qt --with-qt-name Use a specific Qt for building. [default=Qt] passing --with-qt-name=Qt5 will select the other version. just in case: i don't know how to do this properly, and it might change. have a look at .travis.xml, if the above is no longer there. note how the branch breaks qt4 somewhere half way. my idea was to keep qt4 in and functional as long as possible, to allow review against develop. best felix |
From: Attila K. <at...@ki...> - 2018-11-03 11:05:31
|
Moin, On Sun, 2 Sep 2018 18:19:44 +0200 Felix Salfelder <fe...@sa...> wrote: > I made some progress on the qt5 port, started a develop+qt5 branch [1]. > it's now at revision 5, develop+qt5-5. it's all based on develop (not > forking). I wanted to give the qt5 port a try, but it still builds against qt4. I checked out the develop+qt5-6 branch and looked for any switch I might have forgotten, but couldn't find anything. Is there a magic incantation I have to use, or is it something else I am missing? Attila Kinali -- <JaberWorky> The bad part of Zurich is where the degenerates throw DARK chocolate at you. |