From: Guilherme B. T. <gui...@gm...> - 2014-01-08 18:55:50
|
Hello, Just to start the discussion, what do you guys thing about a new stable release in the next months? The last stable was released about 6 months ago. A few crashes and hangs were fixed since them. What do you think about setting a deadline to clean up the existing tickets and move on to release 0.0.18. Regards, Guilherme |
From: Richard <r.c...@ed...> - 2014-01-09 10:06:51
|
On 08/01/2014 18:55, Guilherme Brondani Torri wrote: > Hello, > > Just to start the discussion, what do you guys thing about a new stable > release in the next months? > > The last stable was released about 6 months ago. A few crashes and hangs > were fixed since them. > > What do you think about setting a deadline to clean up the existing > tickets and move on to release 0.0.18. > > Regards, > Guilherme > I would also like to do this, although I would also really like to merge in my qucs_namespace branch before this. I have already merged Bastien's simplifywithouteigen20131209 into qucs_namespace. Although there were some issues with this (see bottom). In qucs_namespace I have also been addressing bug #128 about the switches, by adding a small transition time to the switch. This needs refined a little though, possibly by adding a couple of optional parameters to the switch. I've also switched to zip archives for the examples and a couple of other things. Today I will try to get round to running the updated python test suite again on qucs_namespace. I think a release toward the end of the month would be possible. -------------------------------------- simplifywithouteigen20131209 merge issue: when I merged this branch into mine I noticed that Bastien had modified complex.h with things like this: #ifndef HAVE_CXX_COMPLEX_ACOSH namespace std { nr_complex_t acosh (const nr_complex_t); } #endif where he puts our version of acosh into the standard namespace if it's not declared. I think this is not a good thing to do. It could cause problems for users in the future who use the qucs library and I just don't think it is good practice to pollute the standard namespace with our functions (other agree:http://stackoverflow.com/questions/5683794/bad-practice-to-declare-names-in-the-standard-namespace). Instead I have used things like this: namespace qucs { .... other stuff #ifndef HAVE_CXX_COMPLEX_ACOSH nr_complex_t acosh (const nr_complex_t); #else inline nr_complex_t acosh (const nr_complex_t z) { return std::acosh (z); } #endif .... other stuff } and everywhere in the sources called qucs::acosh rather than std::acosh. The compiler will probably optimise away the function call overhead this introduces if we're using the inline function. ------------------------------------------- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Frans S. <fra...@gm...> - 2014-01-09 11:51:35
|
Hello, I also think it is time for a new release. I have especially heard some complaints from people about the progress of the simulation that doesn't always finish in 0.0.17, this is fixed later on. So let's wait for the qucs_namespace branch to be merged, and then create at least one snapshot release. Frans On 01/09/2014 11:06 AM, Richard wrote: > On 08/01/2014 18:55, Guilherme Brondani Torri wrote: >> Hello, >> >> Just to start the discussion, what do you guys thing about a new stable >> release in the next months? >> >> The last stable was released about 6 months ago. A few crashes and hangs >> were fixed since them. >> >> What do you think about setting a deadline to clean up the existing >> tickets and move on to release 0.0.18. >> >> Regards, >> Guilherme >> > I would also like to do this, although I would also really like to merge > in my qucs_namespace branch before this. I have already merged Bastien's > simplifywithouteigen20131209 into qucs_namespace. Although there were > some issues with this (see bottom). > > In qucs_namespace I have also been addressing bug #128 about the > switches, by adding a small transition time to the switch. This needs > refined a little though, possibly by adding a couple of optional > parameters to the switch. I've also switched to zip archives for the > examples and a couple of other things. > > Today I will try to get round to running the updated python test suite > again on qucs_namespace. > > I think a release toward the end of the month would be possible. > > -------------------------------------- > > simplifywithouteigen20131209 merge issue: > > when I merged this branch into mine I noticed that Bastien had modified > complex.h with things like this: > > #ifndef HAVE_CXX_COMPLEX_ACOSH > namespace std { > nr_complex_t acosh (const nr_complex_t); > } > #endif > > where he puts our version of acosh into the standard namespace if it's > not declared. I think this is not a good thing to do. It could cause > problems for users in the future who use the qucs library and I just > don't think it is good practice to pollute the standard namespace with > our functions (other > agree:http://stackoverflow.com/questions/5683794/bad-practice-to-declare-names-in-the-standard-namespace). > Instead I have used things like this: > > namespace qucs { > > .... other stuff > > > #ifndef HAVE_CXX_COMPLEX_ACOSH > nr_complex_t acosh (const nr_complex_t); > #else > inline nr_complex_t acosh (const nr_complex_t z) { > return std::acosh (z); > } > #endif > > > .... other stuff > > } > > and everywhere in the sources called qucs::acosh rather than std::acosh. > The compiler will probably optimise away the function call overhead this > introduces if we're using the inline function. > > ------------------------------------------- > > Richard > |
From: Bastien R. <rou...@gm...> - 2014-01-10 06:56:42
|
Le 9 janv. 2014 11:06, "Richard" <r.c...@ed...> a écrit : > > On 08/01/2014 18:55, Guilherme Brondani Torri wrote: > > Hello, > > > > Just to start the discussion, what do you guys thing about a new stable > > release in the next months? > > > > The last stable was released about 6 months ago. A few crashes and hangs > > were fixed since them. > > > > What do you think about setting a deadline to clean up the existing > > tickets and move on to release 0.0.18. > > > > Regards, > > Guilherme > > > > I would also like to do this, although I would also really like to merge > in my qucs_namespace branch before this. I have already merged Bastien's > simplifywithouteigen20131209 into qucs_namespace. Although there were > some issues with this (see bottom). > > In qucs_namespace I have also been addressing bug #128 about the > switches, by adding a small transition time to the switch. This needs > refined a little though, possibly by adding a couple of optional > parameters to the switch. I've also switched to zip archives for the > examples and a couple of other things. > > Today I will try to get round to running the updated python test suite > again on qucs_namespace. > > I think a release toward the end of the month would be possible. > > -------------------------------------- > > simplifywithouteigen20131209 merge issue: > > when I merged this branch into mine I noticed that Bastien had modified > complex.h with things like this: > > #ifndef HAVE_CXX_COMPLEX_ACOSH > namespace std { > nr_complex_t acosh (const nr_complex_t); > } > #endif > > where he puts our version of acosh into the standard namespace if it's > not declared. I think this is not a good thing to do. It could cause > problems for users in the future who use the qucs library and I just > don't think it is good practice to pollute the standard namespace with > our functions (other > agree: http://stackoverflow.com/questions/5683794/bad-practice-to-declare-names-in-the-standard-namespace ). Yes and no. These function are part of internal qucs ABI if we export it (using some refinement and.libtool export script we would render non exportable to other binaries) Moreover I add it to std only if this function are part of the std on the norm. I locally render conformant a non conformant implementation. So yes it is a problem now but it work for our case. > Instead I have used things like this: > > namespace qucs { > > .... other stuff > > > #ifndef HAVE_CXX_COMPLEX_ACOSH > nr_complex_t acosh (const nr_complex_t); > #else > inline nr_complex_t acosh (const nr_complex_t z) { > return std::acosh (z); > } > #endif And we polute global namespace for no gain. Standard say std:: acosh is math acosh. Why should I call it qucs acosh for please of broken (windows) implementation? Let the optimize the common case (consider c++ well implemented) and implement kludge for broken implementation. The best solution is to put your replacement to a private namespace and use in config.h #if broken Namespace std { Static inline acosh(x) { return std::qucs::acosh(x); } } Due to static linking other lib does not see it and if you bare config.h in other lib you are evil (you must privatize it). The best is the enemy of the good. Creating a stable and sane lib abi will be hard even on Linux and next to impossible on windows. Let treat sane case first and mark this item to the todo list for now. Bastien Bastien > .... other stuff > > } > > and everywhere in the sources called qucs::acosh rather than std::acosh. > The compiler will probably optimise away the function call overhead this > introduces if we're using the inline function. > > ------------------------------------------- > > Richard > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel |
From: Richard C. <r.c...@ed...> - 2014-01-10 10:18:16
|
On 10/01/2014 06:56, Bastien ROUCARIES wrote: > > Le 9 janv. 2014 11:06, "Richard" <r.c...@ed... > <mailto:r.c...@ed...>> a écrit : > > > > On 08/01/2014 18:55, Guilherme Brondani Torri wrote: > > Yes and no. These function are part of internal qucs ABI if we export it > (using some refinement and.libtool export script we would render non > exportable to other binaries) > > Moreover I add it to std only if this function are part of the std on > the norm. I locally render conformant a non conformant implementation. > Shouldn't the rule should be: Do not add *anything* to the standard namespace? There is a high risk of causing problems by adding things to the std namespace and the standard itself advises against this apart from a few exceptions. Also it is not just about conformant/nonconformant, it is also about backwards compatibility, and not absolutely requiring C++11. > So yes it is a problem now but it work for our case. > > Instead I have used things like this: > > > > namespace qucs { > > > > .... other stuff > > > > > > #ifndef HAVE_CXX_COMPLEX_ACOSH > > nr_complex_t acosh (const nr_complex_t); > > #else > > inline nr_complex_t acosh (const nr_complex_t z) { > > return std::acosh (z); > > } > > #endif > > And we polute global namespace for no gain. Standard say std:: acosh is > math acosh. Why should I call it qucs acosh for please of broken > (windows) implementation? Let the optimize the common case (consider c++ > well implemented) and implement kludge for broken implementation. > I don't understand, how am I polluting the global namespace with this? The new function is in the qucs namespace, not the global namespace. Also again, it is not just about broken implementations, it is also about backwards compatibility with older compilers, by which I mean, the older standard. As to why we should call qucs::acosh, well, isn't this because we are not using the standard complex class, we have our own special implementation of complex. Obviously it would be better if we were using std::complex, and did not have our own implementation, but we are not, so it makes sense to call qucs::acosh since we are using our own implementation. If nothing else, it also warns that it may not be the std implementation throughout the sources. When std::complex does everything we want, we can simply find and replace qucs::funcname with std::funcname everywhere and delete our complex class. Do you mind if I merge my version to master for now? Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Frans S. <fra...@gm...> - 2014-01-23 14:59:21
|
Hello all, I see that Richard has merged his branch qucs_namespace, I am now building a snapshot for Ubuntu / source / windows, so we can test a few things. There are also a few open bugs that may need some attention. When hear people talk about qucs, I often get the question "doesn't qucs deserve a version number higher than 0.0.x?" What do you think about this, shouldn't we at least go to version 0.1.0 or something? Frans On 01/10/2014 11:18 AM, Richard Crozier wrote: > On 10/01/2014 06:56, Bastien ROUCARIES wrote: >> Le 9 janv. 2014 11:06, "Richard" <r.c...@ed... >> <mailto:r.c...@ed...>> a écrit : >> > >> > On 08/01/2014 18:55, Guilherme Brondani Torri wrote: >> >> Yes and no. These function are part of internal qucs ABI if we export it >> (using some refinement and.libtool export script we would render non >> exportable to other binaries) >> >> Moreover I add it to std only if this function are part of the std on >> the norm. I locally render conformant a non conformant implementation. >> > > Shouldn't the rule should be: Do not add *anything* to the standard > namespace? There is a high risk of causing problems by adding things to > the std namespace and the standard itself advises against this apart > from a few exceptions. > > Also it is not just about conformant/nonconformant, it is also about > backwards compatibility, and not absolutely requiring C++11. > > >> So yes it is a problem now but it work for our case. >> > Instead I have used things like this: >> > >> > namespace qucs { >> > >> > .... other stuff >> > >> > >> > #ifndef HAVE_CXX_COMPLEX_ACOSH >> > nr_complex_t acosh (const nr_complex_t); >> > #else >> > inline nr_complex_t acosh (const nr_complex_t z) { >> > return std::acosh (z); >> > } >> > #endif >> >> And we polute global namespace for no gain. Standard say std:: acosh is >> math acosh. Why should I call it qucs acosh for please of broken >> (windows) implementation? Let the optimize the common case (consider c++ >> well implemented) and implement kludge for broken implementation. >> > > I don't understand, how am I polluting the global namespace with this? > The new function is in the qucs namespace, not the global namespace. > > Also again, it is not just about broken implementations, it is also > about backwards compatibility with older compilers, by which I mean, the > older standard. > > As to why we should call qucs::acosh, well, isn't this because we are > not using the standard complex class, we have our own special > implementation of complex. Obviously it would be better if we were using > std::complex, and did not have our own implementation, but we are not, > so it makes sense to call qucs::acosh since we are using our own > implementation. If nothing else, it also warns that it may not be the > std implementation throughout the sources. When std::complex does > everything we want, we can simply find and replace qucs::funcname with > std::funcname everywhere and delete our complex class. > > Do you mind if I merge my version to master for now? > > Richard > |
From: Richard <r.c...@ed...> - 2014-01-23 15:26:05
|
Frans, Let me know if there's any problems, qucsator passed all make check tests, and all tests in python testsuite before I pushed. One option might be to simply drop the 0.0. and just call it Qucs 18, I think people have probably thought of the previous versions as being full version numbers really. We could then start from 18.1 18.2 etc. in future. I haven't really thought this through though, and don't feel particularly strongly about it either. Richard On 23/01/2014 14:59, Frans Schreuder wrote: > Hello all, > > I see that Richard has merged his branch qucs_namespace, I am now > building a snapshot for Ubuntu / source / windows, so we can test a few > things. > There are also a few open bugs that may need some attention. > > When hear people talk about qucs, I often get the question "doesn't qucs > deserve a version number higher than 0.0.x?" > What do you think about this, shouldn't we at least go to version 0.1.0 > or something? > > Frans > > On 01/10/2014 11:18 AM, Richard Crozier wrote: >> On 10/01/2014 06:56, Bastien ROUCARIES wrote: >>> Le 9 janv. 2014 11:06, "Richard" <r.c...@ed... >>> <mailto:r.c...@ed...>> a écrit : >>> > >>> > On 08/01/2014 18:55, Guilherme Brondani Torri wrote: >>> >>> Yes and no. These function are part of internal qucs ABI if we export it >>> (using some refinement and.libtool export script we would render non >>> exportable to other binaries) >>> >>> Moreover I add it to std only if this function are part of the std on >>> the norm. I locally render conformant a non conformant implementation. >>> >> >> Shouldn't the rule should be: Do not add *anything* to the standard >> namespace? There is a high risk of causing problems by adding things to >> the std namespace and the standard itself advises against this apart >> from a few exceptions. >> >> Also it is not just about conformant/nonconformant, it is also about >> backwards compatibility, and not absolutely requiring C++11. >> >> >>> So yes it is a problem now but it work for our case. >>> > Instead I have used things like this: >>> > >>> > namespace qucs { >>> > >>> > .... other stuff >>> > >>> > >>> > #ifndef HAVE_CXX_COMPLEX_ACOSH >>> > nr_complex_t acosh (const nr_complex_t); >>> > #else >>> > inline nr_complex_t acosh (const nr_complex_t z) { >>> > return std::acosh (z); >>> > } >>> > #endif >>> >>> And we polute global namespace for no gain. Standard say std:: acosh is >>> math acosh. Why should I call it qucs acosh for please of broken >>> (windows) implementation? Let the optimize the common case (consider c++ >>> well implemented) and implement kludge for broken implementation. >>> >> >> I don't understand, how am I polluting the global namespace with this? >> The new function is in the qucs namespace, not the global namespace. >> >> Also again, it is not just about broken implementations, it is also >> about backwards compatibility with older compilers, by which I mean, the >> older standard. >> >> As to why we should call qucs::acosh, well, isn't this because we are >> not using the standard complex class, we have our own special >> implementation of complex. Obviously it would be better if we were using >> std::complex, and did not have our own implementation, but we are not, >> so it makes sense to call qucs::acosh since we are using our own >> implementation. If nothing else, it also warns that it may not be the >> std implementation throughout the sources. When std::complex does >> everything we want, we can simply find and replace qucs::funcname with >> std::funcname everywhere and delete our complex class. >> >> Do you mind if I merge my version to master for now? >> >> Richard >> > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > Qucs-devel mailing list > Quc...@li... > https://lists.sourceforge.net/lists/listinfo/qucs-devel > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
From: Guilherme B. T. <gui...@gm...> - 2014-01-23 17:12:01
|
Hi, On 23/01/14 16:25, Richard wrote: > Frans, > > Let me know if there's any problems, qucsator passed all make check > tests, and all tests in python testsuite before I pushed. Nice! I'm pulling right now. > > One option might be to simply drop the 0.0. and just call it Qucs 18, I > think people have probably thought of the previous versions as being > full version numbers really. We could then start from 18.1 18.2 etc. in > future. > > I haven't really thought this through though, and don't feel > particularly strongly about it either. > > Richard > > On 23/01/2014 14:59, Frans Schreuder wrote: >> Hello all, >> >> I see that Richard has merged his branch qucs_namespace, I am now >> building a snapshot for Ubuntu / source / windows, so we can test a few >> things. >> There are also a few open bugs that may need some attention. >> >> When hear people talk about qucs, I often get the question "doesn't qucs >> deserve a version number higher than 0.0.x?" >> What do you think about this, shouldn't we at least go to version 0.1.0 >> or something? >> >> Frans >> >> I rather like the major.minor.patch version numbers. I find it nice to use an odd/even minor for development/stable releases. Perhaps we can find a relation with the Qucs roadmap (which we should revise/extend/document), to indicate how far have we got. At this point we are quite far from a 1.0.0 (complete version)... It is really up to us to define and stick to a meaningful representation. I would go with either 0.0.18 or 0.1.0. Regards, Guilherme |
From: Guilherme B. T. <gui...@gm...> - 2014-01-10 08:26:57
|
On 09/01/14 12:51, Frans Schreuder wrote: <snip> > So let's wait for the qucs_namespace branch to be merged, and then > create at least one snapshot release. > Sounds good to me! <snip> > Today I will try to get round to running the updated python test suite > again on qucs_namespace. Indeed I recently updated the tests, thanks to Clemens the data parser was fixed. Now just 2 projects do not run. One is a problem in Qucs schematic and the other is related to Diodes with an area with a value of "Normal". These are likely to be corrupted projects. By the way, I believe it is best to leave qucs-test in a separate repository. In this way we can move back and forth on the qucs commits while keeping the tests frozen. > > I think a release toward the end of the month would be possible. > > <snip> End of February would be even better for me. I am busy preparing for a conference in the end of this month. Regards, Guilherme |
From: Richard C. <r.c...@ed...> - 2014-01-10 09:27:17
|
On 10/01/2014 08:26, Guilherme Brondani Torri wrote: > On 09/01/14 12:51, Frans Schreuder wrote: > > <snip> >> So let's wait for the qucs_namespace branch to be merged, and then >> create at least one snapshot release. >> > Sounds good to me! > > <snip> >> Today I will try to get round to running the updated python test suite >> again on qucs_namespace. > > Indeed I recently updated the tests, thanks to Clemens the data parser > was fixed. > Now just 2 projects do not run. One is a problem in Qucs schematic and > the other is related to Diodes with an area with a value of "Normal". > These are likely to be corrupted projects. > By the way, I believe it is best to leave qucs-test in a separate > repository. In this way we can move back and forth on the qucs commits > while keeping the tests frozen. >> >> I think a release toward the end of the month would be possible. >> >> > <snip> > > End of February would be even better for me. I am busy preparing for a > conference in the end of this month. > > Regards, > Guilherme > Ok, I agree with everything you suggest. Regarding the releasy, actually I would also be happy to wait till longer than the end of the month, but thought maybe you would want sooner, so I'm ok to wait. Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |