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: Gopala K. <kri...@gm...> - 2006-09-08 05:44:26
|
Hello Stefan, > Probably you can improve the situation by a library.!? :-] I will see this matter a bit later . > This doesn't count!!! > A little comparison: A bluescreen in Windows tells the user there is > something wrong. But it simply annoys a user and does not make him write > a bug report. > Though this comparison is somewhat unfair, it clarifies my opinion. But still bugs are quite rare in release versions (tested). And bugs anywhere , either in main app or tools are to be fixed !! So , whether the whole app crashes or only the tool crashes , any of these means BUG. But to support your concern ,we can introduce autosave feature to overcome this. This is what I feel is better. > This is right. > > For developers who want improve a section of code somewhere in Qucs > it may be easier to understand a "smaller" individual program rather > than understanding the whole application (though she/he doesn't need > to). Also it inhibits "side-effects" as changes to a tool (when > located in a big app) become more substantial. Since we maintain separate classes for separate tools ,the developer interested in specific part of specific tool can easily concentrate on only those classes. I also told you that we can maintain separate folders for separate tools. I also assure you that there won't be any side effects since these tools just use the settings part of qucs application and nothing else. But never the less , I feel the current structure of the qucs application is not bad(not at all !!). The current structure has its own advantages as pointed by you. What I wanted was to reduce some code by resuse and to make the tool to be used without starting new processes. I don't have any problems with current structure, though !! :-) So what is your opinion now? -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2006-09-07 11:50:48
|
Am Do, 7.09.2006, 11:11, schrieb Gopala Krishna: > Hello Stefan, Hi Gopala, > First of all thanks for your early response :-) >> Well, the major work was done, before committing... > Got it ! But I meant there won't be much changes in transcalc as of now :) Except adding more types of transmission lines. >> Basically I do like the idea of having different applications for >> different >> tasks. As long as the interface between these applications is >> suffieciently >> easy... Having different programs also makes maintainance a bit easier. >> Of course, code-reuse would be easier if we had one big application. >> But >> this can also be achieved by using libraries which are shared by >> applications. > > I don't see any differences in maintainance if the code will be > merged. Even though the code will be merged we need not clutter them. > We can have a directory called tools and in that we can again have > separate directories for each tool. > May be you meant testing the tool will be easy after any > modification. But you can see that each tool has tQucsSettings defined > separately to suit their needs. Instead one singleton class would > suffice if the tool were to be used as part of the main application. > Also you need to have main function for each program with > Menubar,toolbar and you need to again define > loadSettings(),saveSettings() ..so we lose the advantages of code > reuse. Also new tools will be added in future as qucs progresses and > the same processes described above has to be followed to each. I see your point. I also wished code-sharing exactly for the above items you mentioned. > But your shared library idea is good :-) Probably you can improve the situation by a library.!? :-] >> Generally spoken performance is not a criteria right now, but stability >> should be. Also I think we wouldn't gain any speed when having one big >> application. I just doubt that. Imagine you have a small little bug >> in the attenuator app which causes a segfault. That would crash the >> application, which is not what you want I think. > > But anyway , bugs are BUGS and are meant to be fixed. Just think > a person will be using a tool which segfaults .While using the tool , > suddenly it disappears without any error message . Or sometimes the > tool may not even start. Then that person will be more confused. This > is because the person won't know that only the tool crashed. So he > will rarely report this !! > But suppose the application crashes. Then the user will know > that the application crashed and there is good chance he will report > this bug and hopefully this will be fixed ! :-) This doesn't count!!! A little comparison: A bluescreen in Windows tells the user there is something wrong. But it simply annoys a user and does not make him write a bug report. Though this comparison is somewhat unfair, it clarifies my opinion. >> Thus your point about the tools being "much use as individual programs" >> I don't agree with. For instance someone could make an effort to export >> SPICE netlists from these (e.g. for the filters), then the program is of >> use "as individual program" independent from Qucs... > > Yes , I agree that the tool "as individual program" is not > useless. But I think only a few of the users will use these tools > individually. That too , at present ,they are more useful with qucs. > I don't mean useless otherwise. Also no one can/will download only > tools without qucs. > As you mentioned about SPICE example, that can be done eventhough the > tool is not individual program. This is right. For developers who want improve a section of code somewhere in Qucs it may be easier to understand a "smaller" individual program rather than understanding the whole application (though she/he doesn't need to). Also it inhibits "side-effects" as changes to a tool (when located in a big app) become more substantial. Cheers, Stefan. |
From: Gopala K. <kri...@gm...> - 2006-09-07 09:11:18
|
Hello Stefan, First of all thanks for your early response :-) > Well, the major work was done, before committing... Got it ! But I meant there won't be much changes in transcalc as of now :) > Whose work? Authors of transcalc(Gopal Narayanan and Claudio Giradi) > Do you agree? Perhaps , not exactly Stefan. > Basically I do like the idea of having different applications for different > tasks. As long as the interface between these applications is suffieciently > easy... Having different programs also makes maintainance a bit easier. > Of course, code-reuse would be easier if we had one big application. But > this can also be achieved by using libraries which are shared by > applications. I don't see any differences in maintainance if the code will be merged. Even though the code will be merged we need not clutter them. We can have a directory called tools and in that we can again have separate directories for each tool. May be you meant testing the tool will be easy after any modification. But you can see that each tool has tQucsSettings defined separately to suit their needs. Instead one singleton class would suffice if the tool were to be used as part of the main application. Also you need to have main function for each program with Menubar,toolbar and you need to again define loadSettings(),saveSettings() ..so we lose the advantages of code reuse. Also new tools will be added in future as qucs progresses and the same processes described above has to be followed to each. But your shared library idea is good :-) > Generally spoken performance is not a criteria right now, but stability > should be. Also I think we wouldn't gain any speed when having one big > application. I just doubt that. Imagine you have a small little bug > in the attenuator app which causes a segfault. That would crash the > application, which is not what you want I think. But anyway , bugs are BUGS and are meant to be fixed. Just think a person will be using a tool which segfaults .While using the tool , suddenly it disappears without any error message . Or sometimes the tool may not even start. Then that person will be more confused. This is because the person won't know that only the tool crashed. So he will rarely report this !! But suppose the application crashes. Then the user will know that the application crashed and there is good chance he will report this bug and hopefully this will be fixed ! :-) > Thus your point about the tools being "much use as individual programs" > I don't agree with. For instance someone could make an effort to export > SPICE netlists from these (e.g. for the filters), then the program is of > use "as individual program" independent from Qucs... Yes , I agree that the tool "as individual program" is not useless. But I think only a few of the users will use these tools individually. That too , at present ,they are more useful with qucs. I don't mean useless otherwise. Also no one can/will download only tools without qucs. As you mentioned about SPICE example, that can be done eventhough the tool is not individual program. Am I right ? If not do enlighten me :-) -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2006-09-07 08:14:37
|
Am Do, 7.09.2006, 09:06, schrieb Gopala Krishna: > Hello Stefan, Hi Gopala, > I am facing few problem in porting Qucs-Transcalc. The problem is > it uses some classes like QHBox,QVBox,QHButtonGroup... which are > deprecated in Qt4 and available only in Qt3 support libs. All these > have to be replaced by Q*Layout alternatives which is quite confusing > for me since some functions use QVBox** as their arguments and loops > over this. > I understand that Qucs-transcalc was originally ported from gtk > to qt. But I could see from that site that there was no major work > being done (unfortunately the commit statistics are not available for > cvs). Well, the major work was done, before committing... > So, I feel we can redesign this app to be more organised as well as > more robust. I don't mean that , it is not robust now. But we can > atleast improve and build upon their work. Whose work? > I do have to discuss one more point with you. The qucs tools i.e > attenuator, transcalc, edit, filter and lib (everything except help) > are meant to be used with qucs. I mean they may not be of much use as > individual programs (correct and excuse me if I'm wrong ). We can > easily merge the code into main qucs and use these tools by creating > the respective objects of their own when needed instead of creating > new processes for them. This also improves the performance of the > system. > > So, what is your opinion about my views ? > Please excuse me if I am wrong and do enlighten me in that case :-) Basically I do like the idea of having different applications for different tasks. As long as the interface between these applications is suffieciently easy... Having different programs also makes maintainance a bit easier. Of course, code-reuse would be easier if we had one big application. But this can also be achieved by using libraries which are shared by applications. Generally spoken performance is not a criteria right now, but stability should be. Also I think we wouldn't gain any speed when having one big application. I just doubt that. Imagine you have a small little bug in the attenuator app which causes a segfault. That would crash the application, which is not what you want I think. Thus your point about the tools being "much use as individual programs" I don't agree with. For instance someone could make an effort to export SPICE netlists from these (e.g. for the filters), then the program is of use "as individual program" independent from Qucs... Do you agree? Stefan. |
From: Gopala K. <kri...@gm...> - 2006-09-07 07:07:04
|
Hello Stefan, I am facing few problem in porting Qucs-Transcalc. The problem is it uses some classes like QHBox,QVBox,QHButtonGroup... which are deprecated in Qt4 and available only in Qt3 support libs. All these have to be replaced by Q*Layout alternatives which is quite confusing for me since some functions use QVBox** as their arguments and loops over this. I understand that Qucs-transcalc was originally ported from gtk to qt. But I could see from that site that there was no major work being done (unfortunately the commit statistics are not available for cvs). So, I feel we can redesign this app to be more organised as well as more robust. I don't mean that , it is not robust now. But we can atleast improve and build upon their work. I do have to discuss one more point with you. The qucs tools i.e attenuator, transcalc, edit, filter and lib (everything except help) are meant to be used with qucs. I mean they may not be of much use as individual programs (correct and excuse me if I'm wrong ). We can easily merge the code into main qucs and use these tools by creating the respective objects of their own when needed instead of creating new processes for them. This also improves the performance of the system. So, what is your opinion about my views ? Please excuse me if I am wrong and do enlighten me in that case :-) -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2006-09-05 13:49:49
|
Am Di, 5.09.2006, 15:29, schrieb Gopala Krishna: > Hello Stefan, Hi Gopala, >> Can you tell how you're going to continue? > > I plan to initially port all small components > (qucs-lib,qucs-attenuator,qucs-edit,qucs-filter ..) of the app . By > then I would have gained some experience in porting. Later I will port > the main qucs app. Sounds reasonable. :-) Thanks for your efforts, Stefan. |
From: Gopala K. <kri...@gm...> - 2006-09-05 13:29:17
|
Hello Stefan, > Can you tell how you're going to continue? I plan to initially port all small components (qucs-lib,qucs-attenuator,qucs-edit,qucs-filter ..) of the app . By then I would have gained some experience in porting. Later I will port the main qucs app. -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2006-09-05 12:38:30
|
Am Mo, 4.09.2006, 14:33, schrieb Gopala Krishna: > Hello all, Hi there! > I have ported the qucs-help application to Qt4.It works pretty > well in my system except for Russian language. This is mostly a > problem with QTextBrowser itself. The problem is that some parts of > text which do not belong to link is also underlined(considered as > link). > So, I request you all to try it and report any bugs, > assert-failures, debug-messages ... > You are also free to give your opinions and comments. > > > To try this > 1) You need check out qucs from branch qucs_0_1_0. > 2) Update QTDIR to point to Qt4 dist. > 3) Run autogen.sh & configure scripts as you usually do. > 4) Go to qucs-help directory and type make > 5) ./qucshelp > ##: If you have set some different prefix in configure, > please copy the qucs folder in share folder of previously compiled > qucs to prefix/share folder since you won't do "make install" . > Otherwise it may not work. Thanks for notification! I've not yet been able to test it, but I am quite sure you're doing the right thing. :-) Can you tell how you're going to continue? Thanks, Stefan. |
From: Stefan J. <st...@gr...> - 2006-09-05 12:09:55
|
Am So, 3.09.2006, 16:06, schrieb mike brinson: > Hello Stefan Hello Mike, Thanks for the email. > Now that Qucs 0.0.10 has been released I am trying to plan my future work > on Qucs digital simulation and analogue modelling. The last few months > have seen Qucs progress at a very fast pace allowing the package to mature > to such an extent that it is now possible to use the software for real > design work. Much work still remains to be done in both digital > simulation and analogue component modelling - both of these are where I > feel I can contribute a useful input to the project. Your contributions were of high value, excellent style and are really appreciated! > The following notes present a rough outline of the topics I propose to > work on over the next few months. I have also posted a copy of this note > to the Qucs development site so that other Qucs developers/users can keep > in contact with the developments I am proposing - I also hope that this > will result in feedback from other Qucs users. > > 1. Digital simulation. > > The second update to the "getting started with digital simulation" gives > an insite into the way digital simulation is developing with Qucs/FreeHDL. > One of the next logic steps forward is to develop libraries of digital > components - this involves the use of VHDL packages, VHDL text files and > libraries of digital component schematics (that are functional of course). > Recently I have tested VHDL packages using Qucs/FreeHDL and find that > they work ok. The next stage is to start writing VHDL libraries of > components which can then be included with future releases of Qucs/VHDL. > At the moment individual digital component schematics are limited to > connections of type bit. In the longer term work needs to be done on > improving the Qucs digital GUI to include both bit and std_logic bus > structures - this however, is more in the domain of Gopala than mine. I > also propose to write a digital component specification booklet that > presents the details of each component, this will be in > a similar format to the Measurements Expressions Reference Manual written > by Gunther. > > 2. Analogue component modelling. > Work on the new 555 timer model is now complete and I will start writing a > tutorial article for posting to the Qucs site in the next few days. A > range of 555 models will also be made available at the time the article is > published. I also propose to update the Operational Amplifier tutorial to > include models for power supply rejection effects in general purpose OP > AMP models. Longer term the analogue modelling effort needs extensions to > Qucs that include subcircuit parameter passing, component values defined > by equations and non-linear controlled sources. These I now are already > on your to do list. Once in place it will then be possible to develop > general purpose models for a wide range of analogue components, > significantly extending the types of circuit that Qucs can simulate. > > The ideas listed above will probably take most of my spare time over the > next few months. > Your comments, and indeed other comments from other developers and users, > will be most welcome. The proposals sound very promising. Don't even know how to thank you for your efforts! Cheers, Stefan. |
From: Gopala K. <kri...@gm...> - 2006-09-04 12:33:22
|
Hello all, I have ported the qucs-help application to Qt4.It works pretty well in my system except for Russian language. This is mostly a problem with QTextBrowser itself. The problem is that some parts of text which do not belong to link is also underlined(considered as link). So, I request you all to try it and report any bugs, assert-failures, debug-messages ... You are also free to give your opinions and comments. To try this 1) You need check out qucs from branch qucs_0_1_0. 2) Update QTDIR to point to Qt4 dist. 3) Run autogen.sh & configure scripts as you usually do. 4) Go to qucs-help directory and type make 5) ./qucshelp ##: If you have set some different prefix in configure, please copy the qucs folder in share folder of previously compiled qucs to prefix/share folder since you won't do "make install" . Otherwise it may not work. -- Cheers, Gopala Krishna A |
From: mike b. <mbr...@ya...> - 2006-09-03 14:06:30
|
Hello Stefan Now that Qucs 0.0.10 has been released I am trying to plan my future work on Qucs digital simulation and analogue modelling. The last few months have seen Qucs progress at a very fast pace allowing the package to mature to such an extent that it is now possible to use the software for real design work. Much work still remains to be done in both digital simulation and analogue component modelling - both of these are where I feel I can contribute a useful input to the project. The following notes present a rough outline of the topics I propose to work on over the next few months. I have also posted a copy of this note to the Qucs development site so that other Qucs developers/users can keep in contact with the developments I am proposing - I also hope that this will result in feedback from other Qucs users. 1. Digital simulation. The second update to the "getting started with digital simulation" gives an insite into the way digital simulation is developing with Qucs/FreeHDL. One of the next logic steps forward is to develop libraries of digital components - this involves the use of VHDL packages, VHDL text files and libraries of digital component schematics (that are functional of course). Recently I have tested VHDL packages using Qucs/FreeHDL and find that they work ok. The next stage is to start writing VHDL libraries of components which can then be included with future releases of Qucs/VHDL. At the moment individual digital component schematics are limited to connections of type bit. In the longer term work needs to be done on improving the Qucs digital GUI to include both bit and std_logic bus structures - this however, is more in the domain of Gopala than mine. I also propose to write a digital component specification booklet that presents the details of each component, this will be in a similar format to the Measurements Expressions Reference Manual written by Gunther. 2. Analogue component modelling. Work on the new 555 timer model is now complete and I will start writing a tutorial article for posting to the Qucs site in the next few days. A range of 555 models will also be made available at the time the article is published. I also propose to update the Operational Amplifier tutorial to include models for power supply rejection effects in general purpose OP AMP models. Longer term the analogue modelling effort needs extensions to Qucs that include subcircuit parameter passing, component values defined by equations and non-linear controlled sources. These I now are already on your to do list. Once in place it will then be possible to develop general purpose models for a wide range of analogue components, significantly extending the types of circuit that Qucs can simulate. The ideas listed above will probably take most of my spare time over the next few months. Your comments, and indeed other comments from other developers and users, will be most welcome. Mike Mike Brinson mbr...@ya... --------------------------------- All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine |
From: Raimund 'R. J. <ra...@lk...> - 2006-09-02 19:36:09
|
asco developer wrote: Hello João! > Writing lacks human expressions and as such does not show the peaceful > state that I'm writing these lines. Take that in mind. no offense taken, i hope i didnt provoke any in you. > Not wanting to extend too much, quoting my text shows that using (1.a) > Makefile or (1.b) Autotools are currently available. As of today I > use more the former while others prefer the latter. > > "As it is, make takes 6 seconds on my computer. With Autotools takes > considerably more. As such, both possibilities are given. The final > user decides with one is better suitable." well, i think i see your point but shipping the autotools stuff in the way you do, they are of no use. it is "dead code" that will cease to do anything useful with the inevitable "bit rot" we all know. as soon as you add the next subdirectory someone has to take some maintenance steps. it's probably not you so some outsider would be required. with the things i pointed out i tried to show you that you're making it pretty hard for outsiders to help even with the most trivial stuff. i _know_ that the autotools are far from being perfect. they induce some headache but eventually they do somethig very important: end users have a standard way to install source-distributed packages. (configure; make; make install). this alone is quite an achivement. other package maintainers solved it by implementing their own 'configure' script (mplayer for example) - they kept the user-visible compile time interface but did the rest on their own. "many roads lead to rome" - dunno if that's an english term, too :) > I can support some architectures. With others, their users will have > to report what is missing to make it possible. Also thinking on > others, a comprehensive manual was written with step-by-step > instructions on how to the optimizer can be used with some commercial > and free electric simulators. The examples existing and distributed > along with the code, support that the final user interest is far from > forgotten. ok, i didnt want to imply you dont care for the rest of us, completely. still you take the "trial and error" approach: wait for someone that needs a new platform - let him fail there, develop a fix afterwards. with the autotools stuff and especially someone like Stefan by your side you can have platforms supported out of the box you dont even know about. we didnt know that qucs would work on mac os X until someone published a pre-compiled package. [...] > Considering that the KDE projecting is switching to CMake, should now > I drop support to Autotools? Should I use Subversion over CVS? Why not > code in PASCAL from now on, because it is so much fast to compile and > without linking issues? My point: there are a couple a right ways of > getting to the same place. yes, i can see the point. as the main developer it is important that you feel comfortable with your environment. but still you should be open for suggestions. if you use Subversion or CVS or any other version management doesnt really matter - but some form of public access to current sources would be greatly beneficial. (for people trying to access the sources or even for you because you dont need to maintain a CVS server or care about the backup too much). > As another point of view, and nothing that SPICE is likely the most > common descriptive language for an electric circuit, why did Qucs > decided to create yet another one? Furthermore, I can also query the > lack of BSIM model? But why stop in here, if for some persons the EKV > model is superior to BSIM? rome, many roads. and for the SPICE language: the complete lack of readability of the parser code and thereby the grammar. i tried it :) > I did avoid making changes where they would break operation for the > other simulators; where would create problems in a distributed > computing situation; or where the existing implementation is superior. > These issues aside, I have seen a cooperative environment and changes > have been made in ASCO to ease operation with the Qucs simulator. and we greatly appreciate that. i already stated that qucs benefits from ASCO - but with the growing user base ASCO can also benefit from qucs. the previous discussion was rather theoretical. i will give you some practical examples of what _could_ happen with public CVS/svn/whatever access and autotools support as many (many!) packages use it: - 'make distcheck' - no packaging errors possible - standard way of installing - standard way of uninstalling ('make uninstall') - compile-tests together with qucs on various platforms and different compilers: solaris, *bsd, linux, amd64, ppc, whatever is reachable - shipping together with qucs: growing user base - package for that other OS: growing user base (!) - a GUI for your application: growing user base (!!) please consider my arguments, i tried to explain the reasons as good as i could. Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
From: asco d. <as...@gm...> - 2006-09-02 16:02:28
|
Hello Raimund, Writing lacks human expressions and as such does not show the peaceful state that I'm writing these lines. Take that in mind. Not wanting to extend too much, quoting my text shows that using (1.a) Makefile or (1.b) Autotools are currently available. As of today I use more the former while others prefer the latter. "As it is, make takes 6 seconds on my computer. With Autotools takes considerably more. As such, both possibilities are given. The final user decides with one is better suitable." I can support some architectures. With others, their users will have to report what is missing to make it possible. Also thinking on others, a comprehensive manual was written with step-by-step instructions on how to the optimizer can be used with some commercial and free electric simulators. The examples existing and distributed along with the code, support that the final user interest is far from forgotten. I do have difficulties in situations where I'm asked: - Why don't you use glibc functions because <insert personal reason in here= >? - Why is ASCO not coded in perl <insert personal reason in here>? - How difficult is to implement <...> I have taken some directions but in any case I have stated that other options, possible better would not be followed in the future. With the enormous possibilities available, I simply feel better with some of them. My comment went in that direction. "At this moment only I'm developing the code which makes the current system the one most fit to me. Linus used email for years, I think that I can use it a little bit more. Furthermore, with the average of 0 patches received each week, as of now I do not see any one looking at the code. If in the future the situation changes, I will adapt according to the requirements." Considering that the KDE projecting is switching to CMake, should now I drop support to Autotools? Should I use Subversion over CVS? Why not code in PASCAL from now on, because it is so much fast to compile and without linking issues? My point: there are a couple a right ways of getting to the same place. As another point of view, and nothing that SPICE is likely the most common descriptive language for an electric circuit, why did Qucs decided to create yet another one? Furthermore, I can also query the lack of BSIM model? But why stop in here, if for some persons the EKV model is superior to BSIM? I did avoid making changes where they would break operation for the other simulators; where would create problems in a distributed computing situation; or where the existing implementation is superior. These issues aside, I have seen a cooperative environment and changes have been made in ASCO to ease operation with the Qucs simulator. Regards, Jo=E3o Ramos |
From: Raimund 'R. J. <ra...@lk...> - 2006-09-02 00:00:14
|
Hello João! my name is Raimund and i'm a friend of Stefan. we develop free software more or less together for several years now and i'm the official CVS slave and general computer science consultant for qucs. i like qucs a lot and i want to help it grow - asco seems to be a very good extension to the field of use for qucs. now, as i understand the situation, you are reluctant to do two things that Stefan (and probably others) would like to see. i'll discuss those points below. you explained that you see no point in streamlining your package in a way everyone is used to because you feel it has too much impact on the way you work. and with noone else contributing you also see no point in optimizing your package for anyone else. from my point of view this argument is the wrong way round. for anyone to contribute to your package you have to make it transparent for them. or this you have to: 1) make it available 2) make it easy to compile and test 3) make it easy to change and ship changes back to you the easier it is for anyone to work with your package on the software development level (i'm not talking domain-specific code here) - the more likely it is that you receive (domain-specific) patches, grow a larger user base and eventually dominate the world (like Linus). 1/3) releasing your source code as named versions is a very good way to make asco available. but for software developers that investigate bugs or suggest changes it is important to have access to unreleased code. 2) please accept that there are various platforms out there (architectures, operating systems, processor models, everything) - many of them are as free as Linux. C being the programming language it is it sometimes needs compile-time tweaking to work correctly (clever #define, extra -libs, you know the game). now, to overcome some of the difficulties people usually have with source-distributed and free software, Stefan asked you for two things: A) accept his patch for autotoolifying the source tree. this has admittedly two disadvantages for you: the compile time may increase some fractions of a second and you might have to maintain the Makefile.am files as well as some generic scripts in the root of your package. i just downloaded and compiled your package. it takes 6s with your build system and I assume with the generated Makefiles it will also take about 6s. compared with qucs asco is a small package. make compiles incrementally anyway, you mostly dont need to wait long. the most difficult part of working with the autotools is setting everything up in the first place. Stefan did this for you so you will have absolutely no trouble with that. you just have to keep in mind to run 'sh autogen.sh' every now and then and to properly name your source files in the Makefile.am files. and even with this someone might help you (but see below). with the autotools you win two major things: "./configure; make; make install" on about every sane platform there is (and perhaps even windoze). this is such an incredible advantage that I just cannot see why you missed this point. example? there is a 64-bit linux on AMD Athlon64/Opteron CPUs that cleanly compiles qucs but executes the number crunching about twice as fast as in 32-bit mode. the autotools allow to support this platform with no extra overhead. qucs also compiles on FreeBSD, OpenBSD, Solaris and various different ports of Linux. this would be close to impossible without the autotools. i can include asco in my sporadic compile-test sessions on those platforms - but i cannot do this when i cannot "configure; make; make install" it. I will _not_ start remembering package-specific build instructions. nobody wants to. if you compiled several packages for your OS you would clearly see why. B) Stefan also asked you about public CVS access via Sourceforge. For me, this feels like a second step, the above mention things are way more important. however, for people to supply patches it is important to have the current code base to patch against. with a public (anonymous) CVS server you get this for free. you dont want to release asco every night, do you? i strongly hope you have a version control system for your own use. if you dont and just hesitate because you have no experience with those we'd all gladly explain all 4 commands you need to know for daily business. it's easy and you win a lot. providing a public CVS repository at sourceforge does not mean everyone can commit. you might start off with read-only access and only accept patches via email. but after 5 days you will see that you can trust Stefan to commit package-maintenance stuff without any problem. the freehdl team did. it's fun to develop in a group, but everyone has to co-operate. to sum it all up: i believe you cannot have any substantial problem with what Stefan suggested. I tried to show the reasoning above. i can however easily see that you might be afraid of some things because you dont understand them, yet. you dont need to be afraid - it's no rocket science and you are not alone (if you meet some minimal requierements for group co-operation). hopefully not sounding too weird, Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
From: Raimund 'R. J. <ra...@lk...> - 2006-09-01 09:43:22
|
Hi *, as you've seen, Stefan just released Qucs 0.0.10 and all cvs modules have been tagged accordingly (qucs_0_0_10 and freehdl_0_0_3). There is also a branch called qucs_0_1_0 which is the place to start the qt4 migration. only the module qucs has been tagged with this. to check it out, do: cvs -d :ext:$YO...@qu...:/cvsroot/qucs co -r qucs_0_1_0 -d qucs-qt4 qucs which will create a directory qucs-qt4 right beside qucs. as Stefan requested, the cvs HEAD remains in the qt3 branch and will eventually be switched to the qt4 branch. good luck, Gopala :) happy hacking, Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
From: Stefan J. <st...@gr...> - 2006-09-01 07:43:24
|
Qucs 0.0.10 has been released. The Qucs project (Qucs = Quite Universal Circuit Simulator) today announced the immediate availability of Qucs 0.0.10, a Qt-based advanced and powerful microwave circuit simulator for GNU/Linux and other UNIXes. Qucs, including all its libraries and its applications, is available as free (as in speech) software under Open Source licenses. Qucs can be obtained in source code from <http://sourceforge.net/projects/qucs>. Features Qucs provides a GUI based on Qt for setting up electrical and electronic circuitry, a simulator, which is able to simulate the small- and large signal as well as the noise behaviour of these circuits. The results can be shown on a special presentation page in different formats (rect, polar, smith, tabular, 3d-cartesian, locus and polar-smith combinations). Pure digital simulations are also supported. Compiling Qucs 0.0.10 The complete source code for Qucs 0.0.10 may be freely downloaded. Instructions on compiling and installing Qucs 0.0.10 are included in the software archive. Only Qt-Libs >= 3.1 (but < 4.x) and the glibc are required. About Qucs Qucs is an independent project of only a few developers, translators, etc, collaborating over the Internet to create and freely distribute a sophisticated, customizable and stable microwave circuit simulator. For enhancing the development speed we are looking for more developers, who want to support the Qucs Project. Changes in this release The new release comes with an attenuator synthesis application, support for nine-valued VHDL logic and user libraries which can be created from subcircuits. Steps have been taken to allow circuit optimization using ASCO in one of the next releases. Data files such as Touchstone, CITIfiles, VCD and IC-CAP model files can be imported using a graphical interface, CSV files can be exported. Projects can be easily exchanged using a project package file. There is now support for a schematic frame and syntax highlighting for VHDL data types and attributes. The simulation backend is now supporting the SVD algorithm as an equation system solver, initial conditions (transient analysis) for L and C are available and the equation solver has a new function signum. Support for IC-CAP model files, ZVR ascii data, CITIfile and Touchstone as import file formats has been added to the qucsconv data converter. Thanks A lot of thanks go to the translators and to the supportive user responses so far encouraging us to improve the software. We couldn't have done it without you! So long, the Qucs team. |
From: Gopala K. <kri...@gm...> - 2006-09-01 06:57:18
|
Hello , Finally after seeing Raimund's mail even I feel we can just go for branch. The GUI code will be changed gradually and not be started from scratch. I thought of new CVS tree because the new code may not be in a workable condition during initial days. But we can overcome this by incorporating Stefan's idea. It is quite a good idea! (Now I understand) -- Cheers, Gopala Krishna A |
From: Stefan J. <st...@gr...> - 2006-09-01 06:21:20
|
Am Fr, 1.09.2006, 08:16, schrieb Mic...@al...: > Hello to all, Hi there! > I think Raimund's idea is quite good ! As far as I know > the Qt4 port is on the way and so is the new release. > Due to lacking time I will hardly contribute to the GUI > code in the next time. So I think there will be just a > few small conflicts when merging Qt3 and Qt4 stuff. > Anyway, I do not want to make the decision, because others > have to pay for it. I do agree to Raimund as well. With a single difference: qucs_0_0_X (qt3) stays HEAD for a while and qucs_0_1_X (qt4) is created additionally. This will change (qucs_0_1_X becomes HEAD) when/if there is a working version. Cheers, Stefan. |
From: <Mic...@al...> - 2006-09-01 06:16:24
|
Hello to all, I think Raimund's idea is quite good ! As far as I know the Qt4 port is on the way and so is the new release. Due to lacking time I will hardly contribute to the GUI code in the next time. So I think there will be just a few small conflicts when merging Qt3 and Qt4 stuff. Anyway, I do not want to make the decision, because others have to pay for it. Regards, Michael > mike brinson wrote: > > good evening! > > [qt4 development in cvs branch or new module] > >> / /I vote for a new CVS tree. > > but whyyyyyy? > > hm. it seems, i'm overvoted - but i demand a recount in florida :) > well, i still vote for the branch-technique with the qt4 stuff > happening in HEAD / qucs_0_1_X and qt3 stuff being maintained in > qucs_0_0_X. > reasoning: CVS meant to be used for such things. with the branching you > have a way of keeping the development of certain code in a history > which you can inspect at any point in time. you can even develop in > parallel and merge incremental changes (patches) between branches. this > is so amazingly cool - why throw it away? > > with the module being copied you loose the version history and the > ability to merge changes. > > there is only one reason that would justify a new tree: a complete > re-write, a start from scratch. if you would throw away the majority of > the code (due to completely different class scheme) than there isnt > much history too keep. perhaps i was missing this point all the time? > > but perhaps you all have too much fear :) here is what we could do: > # release the last official qt3 release > cvs tag -b qucs_qt3 > > cvs -r qucs_qt3 -d qucs-qt3 co qucs > cvs -d qucs-qt4 co qucs # implicit HEAD branch > > now we have a qucs-qt3 and qucs-qt4 directory for disjunct development > - that's all you have been asking about. > > now consider this: a bug is found in some non-GUI related code. a > memory leak is not that improbable. the fix is easy but 30 different > lines have to be modified in foo.c. the procedure is: > > - fix file foo.c in qucs-qt3 > - commit qucs-qt3 and note the version change (1.1.2.1 for example) - > goto qucs-qt4 > - cvs up -j 1.1.2.1 foo.c > > (this should work on multiple files simultanously and tag names as > well, but i didnt try it as i did the above) > > voila - you have merged a fix from the "old" branch into the current > one. of course, this won't work for GUI code and may produce conflicts > in qucs-qt4 but it does reduce trouble incorporating important patches > in both branches. > > i hope someone sees my point here :) > > Raimund > > -- > ___ ___ _____________ > / /| / /_ / ____/ ___/\ Nothing useful for > / / / / _ / / __/ / __\/ more than a decade > / /_/_/ \/ /_/_/ /_/ > {www.|raimi@} /______/__/\._\.____/\.____/\ .org > \._____\._\/\._\.___\/\.___\/ > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, > security? Get stuff done quickly with pre-integrated technology to make > your job easier Download IBM WebSphere Application Server v.1.0.1 based > on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > |
From: Raimund 'R. J. <ra...@lk...> - 2006-08-31 20:29:59
|
mike brinson wrote: good evening! [qt4 development in cvs branch or new module] > / /I vote for a new CVS tree. but whyyyyyy? hm. it seems, i'm overvoted - but i demand a recount in florida :) well, i still vote for the branch-technique with the qt4 stuff happening in HEAD / qucs_0_1_X and qt3 stuff being maintained in qucs_0_0_X. reasoning: CVS meant to be used for such things. with the branching you have a way of keeping the development of certain code in a history which you can inspect at any point in time. you can even develop in parallel and merge incremental changes (patches) between branches. this is so amazingly cool - why throw it away? with the module being copied you loose the version history and the ability to merge changes. there is only one reason that would justify a new tree: a complete re-write, a start from scratch. if you would throw away the majority of the code (due to completely different class scheme) than there isnt much history too keep. perhaps i was missing this point all the time? but perhaps you all have too much fear :) here is what we could do: # release the last official qt3 release cvs tag -b qucs_qt3 cvs -r qucs_qt3 -d qucs-qt3 co qucs cvs -d qucs-qt4 co qucs # implicit HEAD branch now we have a qucs-qt3 and qucs-qt4 directory for disjunct development - that's all you have been asking about. now consider this: a bug is found in some non-GUI related code. a memory leak is not that improbable. the fix is easy but 30 different lines have to be modified in foo.c. the procedure is: - fix file foo.c in qucs-qt3 - commit qucs-qt3 and note the version change (1.1.2.1 for example) - goto qucs-qt4 - cvs up -j 1.1.2.1 foo.c (this should work on multiple files simultanously and tag names as well, but i didnt try it as i did the above) voila - you have merged a fix from the "old" branch into the current one. of course, this won't work for GUI code and may produce conflicts in qucs-qt4 but it does reduce trouble incorporating important patches in both branches. i hope someone sees my point here :) Raimund -- ___ ___ _____________ / /| / /_ / ____/ ___/\ Nothing useful for / / / / _ / / __/ / __\/ more than a decade / /_/_/ \/ /_/_/ /_/ {www.|raimi@} /______/__/\._\.____/\.____/\ .org \._____\._\/\._\.___\/\.___\/ |
From: mike b. <mbr...@ya...> - 2006-08-30 16:49:26
|
Hi All, I vote for a new CVS tree. Mike Mike Brinson mbr...@ya... --------------------------------- All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine |
From: <Mic...@al...> - 2006-08-29 10:39:40
|
Hello, >>> So it is upto you to decide whether to branch or use new cvs tree. >> >> This all seems too much to call it just a "branch". That's why i >> vote for a new CVS tree. > > Ya even I vote for new cvs tree. Me, too ! Regards, Michael |
From: Stefan J. <st...@gr...> - 2006-08-29 10:38:10
|
Am Di, 29.08.2006, 12:03, schrieb asco developer: Hi there! > On 8/29/06, Stefan Jahn <st...@gr...> wrote: > ... >> Yep. A e.g. -o filename command line option is then used to pass the >> requested filename. Or probably in the config file... >> > > See the attached file with the necessary changes. If the command line > has "-o filename", the output files are renamed as you have requested. > Otherwise, functionality is kept as before. > > As an example, try: > asco -qucs bandpass.txt -o filename Thanks. Should be working... BTW: Something like "cp -fp %s.log %s.log > /dev/null" is not any likely to work for e.g. mingw32. You could: #ifdef __MINGW32__ # define COPY_CMD "copy /y %s.log %s.log > NUL" #else # define COPY_CMD "cp -fp %s.log %s.log > /dev/null" #endif and use COPY_CMD where needed instead... Cheers, Stefan. |
From: asco d. <as...@gm...> - 2006-08-29 10:04:03
|
On 8/29/06, Stefan Jahn <st...@gr...> wrote: ... > Yep. A e.g. -o filename command line option is then used to pass the > requested filename. Or probably in the config file... > > Cheers, Stefan. Hello Stefan, See the attached file with the necessary changes. If the command line has "-o filename", the output files are renamed as you have requested. Otherwise, functionality is kept as before. As an example, try: asco -qucs bandpass.txt -o filename Regards, Jo=E3o Ramos |
From: Stefan J. <st...@gr...> - 2006-08-29 09:19:02
|
Am Fr, 18.08.2006, 20:07, schrieb William Flynn: > Hello again qucs team, Hi there! And sorry for my late reply... > When I edit the component so that I can associate it with a spice (.cir) > file , I inputted the location on my system for the .cir file I wanted to > use > (an analog devices spice file for the AD8603 amplifier, as attached). > However > when I click ok or apply , I get the following error message: > > > line 39: syntax error, unexpected Digits, expecting Eol The error which occured was due to the fact that the POLY construct in the controlled source lines were not accepted by the grammar implemented in the qucs converter. Now it accepts these contructs properly. And gives a appropiate warning message which is better to understand. Anyway those analog bahaviour model constructs are not (yet) supported by qucs. This is on my todo list. Though it might not b possible to directly translated those POLY, LAPLACE, FREQ, VALUE, etc. SPICE constructs into Qucs something similiar will be possible some day. Cheers, Stefan. |