Re: [Kicad-developers] I hate even more wxString
On Sun, Apr 28, 2013 at 09:01:11PM +0200, Lorenzo Marcantonio wrote: ... now, I know that this can be fixed using GetChars, but WHY it worked on 2.8 and nobody else with 2.9 encountered this??? Uhm *maybe* I have found the problem. It seems to be caused by wx built with UTF8 and/or STL usage. Time to do some wx rebuild to see if it goes better... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On 04/28/2013 11:58 PM, Lorenzo Marcantonio wrote: On Sun, Apr 28, 2013 at 11:40:07PM -0500, Dick Hollenbeck wrote: Client code is simply that which makes calls to an interface, a class user. I don't see a problem if an interface is richer than its clients need. Since you changed the specifications (an angle can be arbitrary) the client needs to know it too. It's called type contravariance. Example: Client uses int, interface was using int. Interface now uses doubles. - Client get an angle from an object and stores it (incorrectly) in an int. Could be useful. - Client take that angle (which is now truncated) and gives in to another object (which expects a double). Perfectly fine. *However* data was lost in the process. And in C that's a perfectly legal thing to do (some compiler warns, I don't think gcc does) So you have to check clients, too. Bullshit. just call the interface with the right argument. Just tell us where this is not working, rather than some long winded academic horseshit. Better yet, file a bug report. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] I hate even more wxString
On 04/29/2013 08:18 AM, Lorenzo Marcantonio wrote: On Sun, Apr 28, 2013 at 09:01:11PM +0200, Lorenzo Marcantonio wrote: ... now, I know that this can be fixed using GetChars, but WHY it worked on 2.8 and nobody else with 2.9 encountered this??? Uhm *maybe* I have found the problem. It seems to be caused by wx built with UTF8 and/or STL usage. Time to do some wx rebuild to see if it goes better... I had a similar problem - it was enough to turn off --enable-stl (or explicitly add --disable-stl) for wxWidgets library. Unicode toggling did not change much. -- Maciej Sumiński CERN BE-CO-HT e-mail: maciej.sumin...@cern.ch phone: +41 22 767 2251 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On Mon, Apr 29, 2013 at 01:32:40AM -0500, Dick Hollenbeck wrote: Bullshit. just call the interface with the right argument. Strange for someone that just a few days ago lamented for 'too many bugs' in kicad... Sure. *Call* the interface with the *right* argument. The keyword is *call*. It's not academic. The DRC checker works with angles in int. The display and plotting works with angles in int (for display I suppose is fine, altough easy to fix (and anyway they use it as a double inside...), for gerbers and DXF not necessarily). The gerber viewer (mostly) use int angles. The global pad setting dialog uses the int orientation (angle) both for filtering and for setting. Oh right, the last one is not necessarily a bug since you have to specify the angle as tenths of degrees and it doesn't accept decimal entries. Wasn't that desiderable? Would someone notice that? Unlikely. Unless they actually need more than one decidegree of precision (which is desiderable, as you said, otherwise the angles would be still ints). And unless you that want to be paid for fixing bugs I can fix these myself, don't worry. There are 'only' 68 suspicious symbols to be checked in my queue, for this angle type issue. This is one of the reasons I like typedef (I am *NOT* proposing an angle typedef, mind you:D). And this assuming that eeschema is keeping its 90 degree innards. Please, note that I am not saying that double angles are not desiderable or an error. I'm saying that *just* saying that these function take a double is not enough until you have checked that *everyone* that call them is calling them with a *real* double (and not something coming from a double truncated as an int). Oh, by the way, are module orientation too supposed to be double? I counted them too since it seemed logical. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On 04/29/2013 02:40 AM, Lorenzo Marcantonio wrote: On Mon, Apr 29, 2013 at 01:32:40AM -0500, Dick Hollenbeck wrote: Bullshit. just call the interface with the right argument. Please state the file and line number please. The rest is bullshit. Strange for someone that just a few days ago lamented for 'too many bugs' in kicad... Sure. *Call* the interface with the *right* argument. The keyword is *call*. It's not academic. The DRC checker works with angles in int. The display and plotting works with angles in int (for display I suppose is fine, altough easy to fix (and anyway they use it as a double inside...), for gerbers and DXF not necessarily). The gerber viewer (mostly) use int angles. The global pad setting dialog uses the int orientation (angle) both for filtering and for setting. Oh right, the last one is not necessarily a bug since you have to specify the angle as tenths of degrees and it doesn't accept decimal entries. Wasn't that desiderable? Would someone notice that? Unlikely. Unless they actually need more than one decidegree of precision (which is desiderable, as you said, otherwise the angles would be still ints). And unless you that want to be paid for fixing bugs I can fix these myself, don't worry. There are 'only' 68 suspicious symbols to be checked in my queue, for this angle type issue. This is one of the reasons I like typedef (I am *NOT* proposing an angle typedef, mind you:D). And this assuming that eeschema is keeping its 90 degree innards. Please, note that I am not saying that double angles are not desiderable or an error. I'm saying that *just* saying that these function take a double is not enough until you have checked that *everyone* that call them is calling them with a *real* double (and not something coming from a double truncated as an int). Oh, by the way, are module orientation too supposed to be double? I counted them too since it seemed logical. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
Just found this paper. http://swwxguitesting.wefi.net/MPhilThesisChapterSwWxGuiTesting.pdf (about automated gui testing with wx) I personally think more gui code should move from C++ to python for easy development and interactive testing. Keep it going!! Greetings, Edwin van den Oetelaar 2013/4/28 Miguel Angel Ajo miguelan...@nbee.es I agree that some kind of automated QA tests for the project would be great, Adam wolf and I had a conversation about that recently. I've seen many projects dramatically increasing quality because of regression testing. I'm not sure how well is wx prepared for the UI parts, but we can do it for sure at objects level. Even, to reduce the test development time, we could even think of writing the tests in python directly, at least at pcbnew I think it can be done. Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On Sunday, 28 de April de 2013 at 17:54, Brian Sidebotham wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. We would need good support from all, new code requires new tests, and nobody is better suited to devising the tests than the person who specified the new functionality - which means all developers would probably end up writing test cases at some point. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On Apr 29, 2013 3:07 AM, Edwin van den Oetelaar ed...@oetelaar.com wrote: Just found this paper. http://swwxguitesting.wefi.net/MPhilThesisChapterSwWxGuiTesting.pdf (about automated gui testing with wx) I personally think more gui code should move from C++ to python for easy development and interactive testing. Are you hoping portions get rewritten in wxpython? Or just that new code be written in wxpython? How good is wxpython? Keep it going!! Greetings, Edwin van den Oetelaar 2013/4/28 Miguel Angel Ajo miguelan...@nbee.es I agree that some kind of automated QA tests for the project would be great, Adam wolf and I had a conversation about that recently. I've seen many projects dramatically increasing quality because of regression testing. I'm not sure how well is wx prepared for the UI parts, but we can do it for sure at objects level. Even, to reduce the test development time, we could even think of writing the tests in python directly, at least at pcbnew I think it can be done. Miguel Angel Ajo http://www.nbee.es +34911407752 skype: ajoajoajo On Sunday, 28 de April de 2013 at 17:54, Brian Sidebotham wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. We would need good support from all, new code requires new tests, and nobody is better suited to devising the tests than the person who specified the new functionality - which means all developers would probably end up writing test cases at some point. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On Mon, Apr 29, 2013 at 02:56:47AM -0500, Dick Hollenbeck wrote: Please state the file and line number please. OK, one example: In PCB_BASE_FRAME::GlobalChange_PadSettings (pcbnew/globaleditpad.cpp) on line 232 pad_orient is computed from the pad orientation and the module orientation. pad_orient is an int. Later in the function it's used for pad-SetOrientation (after being used for filtering), so it loses precision. You could say that's a bug in the global pad dialog, but shifting the blame doesn't fix the problem. In DRC::doTrackDrc the angle is computed using ArcTangente which returns an int. Not strictly related but it helps (given that just the other day someone talked about numeric instabilities in the DRC). Again, probably nobody would notice it since tracks are mostly multiple of 45 degrees. However in DRC::checkClearancePadToPad the bounding pad polygon is computed from the truncated angle so it could possibly give wrong results (maybe with huge pads :D) The rest is bullshit. Your opinion, not mine. I hope somebody else think the same of me. If angles are defined to be integers you can (usually) put them in doubles; if angles are 'promoted' to doubles and you actually *can* have fractional angles (i.e. fraction of decidegree) you should check that they aren't truncated on the way (when it matters; for screen drawing probably a truncation is not significant). Otherwise you could simply say that the resolution is one decidegree and use a double for convenience (but then why promote it to int in the first place?) Just decide what an angle is. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
Le 29/04/2013 10:39, Lorenzo Marcantonio a écrit : On Mon, Apr 29, 2013 at 02:56:47AM -0500, Dick Hollenbeck wrote: Please state the file and line number please. OK, one example: In PCB_BASE_FRAME::GlobalChange_PadSettings (pcbnew/globaleditpad.cpp) on line 232 pad_orient is computed from the pad orientation and the module orientation. pad_orient is an int. Later in the function it's used for pad-SetOrientation (after being used for filtering), so it loses precision. You could say that's a bug in the global pad dialog, but shifting the blame doesn't fix the problem. Currently, pads and footprint orientations are in 0.1 degrees. In .brd files they are stored in O.1 degrees (for historical reasons). In new code, orientations are (slowly) moved from int to double. to allow a better resolution than 0.1 degree, *in the future*. If the decision to allow more than 0.1 degree is taken, dialogs *and documentation* need to be updated (not just dialogs). Currently, there is no bug. Just we keep in mind when writing new code the fact one day, the orientation could be finer than 0.1 degree. At least it means the boards are no more saved in old .brd format. Currently there is no truncation in pads angles. In DRC::doTrackDrc the angle is computed using ArcTangente which returns an int. Not strictly related but it helps (given that just the other day someone talked about numeric instabilities in the DRC). Again, probably nobody would notice it since tracks are mostly multiple of 45 degrees. However in DRC::checkClearancePadToPad the bounding pad polygon is computed from the truncated angle so it could possibly give wrong results (maybe with huge pads :D) The rest is bullshit. Your opinion, not mine. I hope somebody else think the same of me. If angles are defined to be integers you can (usually) put them in doubles; if angles are 'promoted' to doubles and you actually *can* have fractional angles (i.e. fraction of decidegree) you should check that they aren't truncated on the way (when it matters; for screen drawing probably a truncation is not significant). Otherwise you could simply say that the resolution is one decidegree and use a double for convenience (but then why promote it to int in the first place?) Just decide what an angle is. -- Jean-Pierre CHARRAS ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On Mon, Apr 29, 2013 at 11:02:58AM +0200, jp charras wrote: In new code, orientations are (slowly) moved from int to double. to allow a better resolution than 0.1 degree, *in the future*. If the decision to allow more than 0.1 degree is taken, dialogs *and documentation* need to be updated (not just dialogs). OK, then: the 'desiderable' thing is in the future. Let's say I'm doing a code review for looking where int angles are still being used and fix it, at least in the backend core, then. I'll post the findings to review before committing (that was the plan, anyway). -- Lorenzo Marcantonio Logos Srl smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On Apr 29, 2013 4:21 AM, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: On Mon, Apr 29, 2013 at 11:02:58AM +0200, jp charras wrote: In new code, orientations are (slowly) moved from int to double. to allow a better resolution than 0.1 degree, *in the future*. If the decision to allow more than 0.1 degree is taken, dialogs *and documentation* need to be updated (not just dialogs). OK, then: the 'desiderable' thing is in the future. Let's say I'm doing a code review for looking where int angles are still being used and fix it, at least in the backend core, then. I'll post the findings to review before committing (that was the plan, anyway). Attach a bad board file if you want your code review, the sky is falling, C programmer mentality, bug report, to be perceived as anything but bullshit. Yes I think there are too many bugs, but this is not a bug, and recall that when I wrote that statement, it was a result of you making senseless changes and judgements that introduced the bugs. To use my resistance against your changes as a way to paint me as inconstent will end you up in my spam folder. Actually you've been there for over a year. Nothing says I must dig those messages out anymore. Jean-pierre is able to interface with you now. Frankly I don't find you qualified to 'review' our code. %z With bug reports please include file and line numbers and attach bad board files for those reading your messages. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On 4/28/2013 8:15 PM, Dick Hollenbeck wrote: On Apr 28, 2013 10:54 AM, Brian Sidebotham brian.sidebot...@gmail.com mailto:brian.sidebot...@gmail.com wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. I think it's good idea as long as we think it through before we start implementing them. I want avoid a free for all mentality and then have to go back and clean up the mess. We should set down some preliminary guidelines for testing along the lines of the coding policy before we start actually writing test code. This way developers will no what is expected. I fully support the idea. It will expand the size of the source tree significantly over time, and increase maintainence, but these costs are dwarfed by the benefits. Pyhon itself has quite a developed test harness environment with lots of tests. They were helpful in getting a-ming-us up to a certain confidence level. I did not need an understanding of the test harness environment to use it. The other thing I learned was that python can call arbitrary C functions in an arbitrary dll, even if they are not swigged. I've used the Python unit test framework for testing Python code. I never thought about using it for testing C++ code but it does seem feasible. Does anybody have any experience doing this or are there any examples of anyone else doing this so we can get an idea of what is involved? If the Python testing framework is not adequate, we can always take a look at the Boost testing framework. I looked at this several months ago and it looked like a good fit given that we already have Boost as a dependency and it's feature parity seemed as good as any of the other open source C/C++ testing frameworks and even many of the commercial testing frameworks. We would need good support from all, new code requires new tests, and nobody is better suited to devising the tests than the person who specified the new functionality - which means all developers would probably end up writing test cases at some point. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
Hi Brian, I'm working on a gerber/drill file python script. It's for a popular PCB order, where people upload files and then get a few copies of their board a few weeks later. They currently support uploading your Eagle files, and it'll export gerbers and drills from it, and then give you a graphical preview. I'm doing the same for them for Kicad. Because there's some logic in the wx dialogs that I'm recreating in the python scripts, I'm pretty worried about not matching Kicad. I've got a set of Xpresser scripts that starts up Kicad, opens a board file, and clicks through the various options for gerbers and drills, and then compares the output to the command line script output. Because I already compile every commit, I can set this up to check for regressions. I expect to be finished with the first cut at the gerber/drill generators by Wednesday, but Maker Faire Bay Area is coming up and I need to get some demos ready for Wayne and Layne, so it may slip a few days. Adam Wolf Wayne and Layne, LLC On Mon, Apr 29, 2013 at 7:59 AM, Brian Sidebotham brian.sidebot...@gmail.com wrote: On 28 April 2013 22:19, Miguel Angel Ajo miguelan...@nbee.es wrote: I agree that some kind of automated QA tests for the project would be great, Adam wolf and I had a conversation about that recently. I've seen many projects dramatically increasing quality because of regression testing. I'm not sure how well is wx prepared for the UI parts, but we can do it for sure at objects level. Even, to reduce the test development time, we could even think of writing the tests in python directly, at least at pcbnew I think it can be done. Hi Miguel, Thanks for the feedback. I must admit, I'm not too bothered about UI testing. I expect most things will become plugins anyway, and we may not be in control of a lot of those things. As a first step I think confidence in the DRC and gerber production is really paramount. These are the things people should care about initially. The Python API exposure should definitely be covered too though. This could easily be achieved by a set of python test scripts. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Miscellaneous stuff
On Mon, Apr 29, 2013 at 07:43:30AM -0500, Dick Hollenbeck wrote: Attach a bad board file if you want your code review, the sky is falling, C programmer mentality, bug report, to be perceived as anything but bullshit. Your grammar fails me, or, better I fail to understand you. Maybe my english is not enough for getting your meaning. Anyway I'll do that. If you, or someone else, wants that fine. Sorry for His Royal Majesty for trying to make kicad a better program. You want to find around all the degrees to radian conversion? Please go on. How many different ways do you have to find a segment length? You'll be surprised. I'm not stopping you. I personally think that trying to have some consistence in the code itself is way more productive to fixing consistence in spacing. With this mentality you shouldn't be surprised if you get no more contributions from outside. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On 29 April 2013 01:15, Dick Hollenbeck d...@softplc.com wrote: On Apr 28, 2013 10:54 AM, Brian Sidebotham brian.sidebot...@gmail.com wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. I fully support the idea. It will expand the size of the source tree significantly over time, and increase maintainence, but these costs are dwarfed by the benefits. Pyhon itself has quite a developed test harness environment with lots of tests. They were helpful in getting a-ming-us up to a certain confidence level. I did not need an understanding of the test harness environment to use it. The other thing I learned was that python can call arbitrary C functions in an arbitrary dll, even if they are not swigged. Excellent, it's good to see there is support for testing in the codebase. I realise that this will add significantly to the codebase, but it will mean that bugs in the core at least can be fixed with good confidence in the changes not affecting other functionality. Thanks for your feedback Dick. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On 29 April 2013 13:45, Wayne Stambaugh stambau...@verizon.net wrote: On 4/28/2013 8:15 PM, Dick Hollenbeck wrote: On Apr 28, 2013 10:54 AM, Brian Sidebotham brian.sidebot...@gmail.com mailto:brian.sidebot...@gmail.com wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. I think it's good idea as long as we think it through before we start implementing them. I want avoid a free for all mentality and then have to go back and clean up the mess. We should set down some preliminary guidelines for testing along the lines of the coding policy before we start actually writing test code. This way developers will no what is expected. Inserting regression testing on a codebase like KiCad is a large task, a mountain if you will. Firstly, decide if we want to tackle the mountain. Secondly, discover and explore the routes to the top. Third, pick a route and prepare for the walk. Fourth, start the walk! I think it is a big subject, and that's why I tentatively ask if we're all in favour. If we are, we can start looking at what options are available to us. It is most likely that we will use CTest to execute the tests as that's the easiest way to get our build system to generate a test target. Some simply CTest stuff is covered in this cmake tutorial: http://www.cmake.org/cmake/help/cmake_tutorial.html I fully support the idea. It will expand the size of the source tree significantly over time, and increase maintainence, but these costs are dwarfed by the benefits. Pyhon itself has quite a developed test harness environment with lots of tests. They were helpful in getting a-ming-us up to a certain confidence level. I did not need an understanding of the test harness environment to use it. The other thing I learned was that python can call arbitrary C functions in an arbitrary dll, even if they are not swigged. I've used the Python unit test framework for testing Python code. I never thought about using it for testing C++ code but it does seem feasible. Does anybody have any experience doing this or are there any examples of anyone else doing this so we can get an idea of what is involved? If the Python testing framework is not adequate, we can always take a look at the Boost testing framework. I looked at this several months ago and it looked like a good fit given that we already have Boost as a dependency and it's feature parity seemed as good as any of the other open source C/C++ testing frameworks and even many of the commercial testing frameworks. I've just had a quick look at Boost Test, and it appears to be a pretty clean approach to writing test cases for testing at a function and class level. Best Regards, Brian. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On 04/29/2013 07:45 AM, Wayne Stambaugh wrote: On 4/28/2013 8:15 PM, Dick Hollenbeck wrote: On Apr 28, 2013 10:54 AM, Brian Sidebotham brian.sidebot...@gmail.com mailto:brian.sidebot...@gmail.com wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. I think it's good idea as long as we think it through before we start implementing them. I want avoid a free for all mentality and then have to go back and clean up the mess. We should set down some preliminary guidelines for testing along the lines of the coding policy before we start actually writing test code. This way developers will no what is expected. I fully support the idea. It will expand the size of the source tree significantly over time, and increase maintainence, but these costs are dwarfed by the benefits. Pyhon itself has quite a developed test harness environment with lots of tests. They were helpful in getting a-ming-us up to a certain confidence level. I did not need an understanding of the test harness environment to use it. The other thing I learned was that python can call arbitrary C functions in an arbitrary dll, even if they are not swigged. I've used the Python unit test framework for testing Python code. I never thought about using it for testing C++ code but it does seem feasible. Does anybody have any experience doing this or are there any examples of anyone else doing this so we can get an idea of what is involved? The python regression testsuite that I referred to is about 60% tests that call into C code. This C code, more often than not, resides in C extensions. So by necessity they are using the stack that you ask about, although *through* the python C API. But there is also the interface that Joseph referred to, the _ctypes moduleextension stack. This allows any *C function* to be called, and it must be a *DLL entry point*. a) C function b) DLL entry point It does not have to be swigged. In testing _ctypes, in the python regression test suite, aka unittests, they arbitrarily load windows' kernel.dll, and call functions in there. These are obviously not python aware functions. The main drawbacks are a) and b) above. The positives are the conciseness of python and the access to a reporting UI, wxPython. We could address a) and b) by having a single DLL/DSO specific entrypoint for all tests, with a big switch in there to route to the actual test. This scaffolding has some maintenance cost, and begins to wash out the ease of using python on top, but perhaps not fully. Doing human-less testing on code written for human interaction requires some thought. here is the typical software stack we would want to test. 1) entrypoint called from a hotkey or menu 2) put up dialog, ask for parameters 3) from dialog, call worker function If you want to test worker function, it is probably a C++ member function, or at least should be. Python will have difficulty calling it unless it is swigged. But let's say the bug is in the dialog window and the gathering of parameters from it? Please think about this awhile. Does this not expose a severe limitation to what can be tested? If the Python
Re: [Kicad-developers] Regression Testing
On 04/29/2013 07:51 AM, Dick Hollenbeck wrote: On 04/29/2013 07:45 AM, Wayne Stambaugh wrote: On 4/28/2013 8:15 PM, Dick Hollenbeck wrote: On Apr 28, 2013 10:54 AM, Brian Sidebotham brian.sidebot...@gmail.com mailto:brian.sidebot...@gmail.com wrote: Hi Guys, I'm just catching up with the list, and I saw something that caught my eye as it's something that's been on my mind for a while: -- Dick Hollenbeck wrote: - Right now, I am finding too many bugs in the software ... - We might do well as a team by slowing down and focusing - on reliability and quality not features for awhile. Firstly, - the bugs are damaging to the project. --- I agree with this, there are things I'd like to add to KiCad, but only on-top of something I can be confident I'm not breaking, especially by creating corner case issues. I would like us to think about regression testing using something like CTest (Which would make sense as we're currently using CMake anyway!). We could then publish dashboard regression testing results. I'm aware work is going into making eeschema and PCBNEW essentially into DLL's, so perhaps it's best to wait until that work is complete before starting down this road? In particular I'd like to see regression testing on the DRC, Gerber generation, and the Python exposed API. Probably in that order of priority too. Certainly the Python API changes are already tripping us up, but only when they have already been broken in committed code. Being able to regression test changes to optimisations and code tidying will help that move along anyway as you can be more confident in your changes having complete coverage once the number of tests increases. I am prepared to say that I'll undertake this work too. Obviously it can't start straight away as I'm currently doing work on the Windows scripting build system and python-a-mingw-us packaging. Is anyone against regression testing, or have alternatives that would achieve similar confidence in committed code? My vote is for regression testing. I think it's good idea as long as we think it through before we start implementing them. I want avoid a free for all mentality and then have to go back and clean up the mess. We should set down some preliminary guidelines for testing along the lines of the coding policy before we start actually writing test code. This way developers will no what is expected. Yes, it's a good idea and here are my high level $0.02. I flash back to hardware computer graphic ASIC design days where we could stimulate the input like a host driver and produce an output, a picture. The input was an automatic or interactive script to generate PCI bus cycles. A set of scripts, text were source controlled along with the Verilog source as a set suite that ran a simulation every night. The picture output was verified automaticly by tracking the expected, resultant frame buffer checksum. I havn't looked at the python interface yet as a possibility, but one approach that to me would seem not add a lot of additional code to be considered might be a keystroke record and playback. Other EDA packages I have run into allow the user to start a recording, stop and save it. This kind of feature would require a keyboard shortcut for each menu pulldown. Each recording session would constitute a test in the test suite. Some short, some longer, some like DRC could even start with a partial design file load. Shorter tests should be encouraged as they are easier to debug. Proper automatic output response candidates might be a netlist or maybe the .sch or .pcb file. Such a feature also could be used to generate tutorials. sig Frank Bennett ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
Yes, it's a good idea and here are my high level $0.02. sig Frank Bennett This is becoming a productive brainstorming session. I'd pay more than $0.02 for that idea Frank. ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
We could address a) and b) by having a single DLL/DSO specific entrypoint for
all tests,
with a big switch in there to route to the actual test. This scaffolding has
some
maintenance cost, and begins to wash out the ease of using python on top, but
perhaps not
fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C string is
like a
printf format string.
So it would be possible to make this callable from python and pass all required
arguments
for any worker function. You would have to instantiate the C++ instance before
calling
any member function which is your worker function. But that could be done in
the switch
within the test entrypoint.
test_result TestEntryPoint( aTestNum, formatStringTellingArgumentTypesInTuple,
Tuple )
{
switch( aTestNum )
{
case XYZ:
{
// instantiate what is needed, say obj
// gleen into C++ arguments, those from Tuple by parsing
// formatStringTellingArgumentTypesInTuple
va_args...
// call object member func with C++ form of arguments
in tuple.
result = obj-WorkerFunction( arg1, arg2, arg3 );
// destroy what we instantiated.
}
}
return test_result( result ) ; // telling what just happened.
}
The above could be a seed for better ideas. It is a means of testing any
worker
function from python.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
I have the feeling that setting entry points from Python to C, when not needed
will be an extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or
something that plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and calling
click methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check their
correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to PNG
test theme. (warning: needs extra maintenance when outputs are enhanced or
change, but it will catch unexpected changes)
c) Model testing from python, everything that's swigged out can be tested
from there, and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of this.
The automated tests I've seen so far (in the last two years) generate an xml
standardized files (junit xml format) that's used for reports (I use them in
bamboo at nbee, and also with other client for web ui testing, I've even used
it to generate VHDL testing outputs from ghdl)
http://projects.nbee.es:8085/browse/S12-DEF the bad thing of bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es (http://www.nbee.es/)
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could address a) and b) by having a single DLL/DSO specific entrypoint
for all tests,
with a big switch in there to route to the actual test. This scaffolding
has some
maintenance cost, and begins to wash out the ease of using python on top,
but perhaps not
fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C string
is like a
printf format string.
So it would be possible to make this callable from python and pass all
required arguments
for any worker function. You would have to instantiate the C++ instance
before calling
any member function which is your worker function. But that could be done in
the switch
within the test entrypoint.
test_result TestEntryPoint( aTestNum,
formatStringTellingArgumentTypesInTuple, Tuple )
{
switch( aTestNum )
{
case XYZ:
{
// instantiate what is needed, say obj
// gleen into C++ arguments, those from Tuple by parsing
// formatStringTellingArgumentTypesInTuple
va_args...
// call object member func with C++ form of arguments in tuple.
result = obj-WorkerFunction( arg1, arg2, arg3 );
// destroy what we instantiated.
}
}
return test_result( result ) ; // telling what just happened.
}
The above could be a seed for better ideas. It is a means of testing any
worker
function from python.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
(mailto:kicad-developers@lists.launchpad.net)
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] specctra_export patch to allow nesteted pcb edges
Thomas, Sorry to say that I lost your patch during a computer upgrade. Can you regenerate something or resend it please. Thanks, Dick Dick, please find the modifications against pcbnew 4061 in the attached patch file. Thomas Thanks Thomas. I applied this patch to version 4061 and ran it against the attached board. The board could not be specctra exported. This is the most basic board I could think of to test against. I also tried a board with two inner circles on Edge.Cuts. Also, the patch is littered with unrelated _() to wxT() replacements, which could not be accepted. So even if it did work at all, this is a difficult starting point for me. So I am not convinced there is anything here to work with at this point. Is there something wrong with my board file? Or can you send me a board which will export with this patch? Thanks, Dick (kicad_pcb (version 3) (host pcbnew (2013-04-28 BZR 4117)-testing) (general (links 0) (no_connects 0) (area 159.944999 119.304999 237.565001 172.795001) (thickness 1.6) (drawings 9) (tracks 0) (zones 0) (modules 0) (nets 1) ) (page A3) (layers (15 F.Cu signal) (0 B.Cu signal) (16 B.Adhes user) (17 F.Adhes user) (18 B.Paste user) (19 F.Paste user) (20 B.SilkS user) (21 F.SilkS user) (22 B.Mask user) (23 F.Mask user) (24 Dwgs.User user) (25 Cmts.User user) (26 Eco1.User user) (27 Eco2.User user) (28 Edge.Cuts user) ) (setup (last_trace_width 0.254) (trace_clearance 0.254) (zone_clearance 0.508) (zone_45_only no) (trace_min 0.254) (segment_width 0.2) (edge_width 0.15) (via_size 0.889) (via_drill 0.635) (via_min_size 0.889) (via_min_drill 0.508) (uvia_size 0.508) (uvia_drill 0.127) (uvias_allowed no) (uvia_min_size 0.508) (uvia_min_drill 0.127) (pcb_text_width 0.3) (pcb_text_size 1.5 1.5) (mod_edge_width 0.15) (mod_text_size 1.5 1.5) (mod_text_width 0.15) (pad_size 1.524 1.524) (pad_drill 0.762) (pad_to_mask_clearance 0.2) (aux_axis_origin 0 0) (visible_elements FF7F) (pcbplotparams (layerselection 3178497) (usegerberextensions true) (excludeedgelayer true) (linewidth 10) (plotframeref false) (viasonmask false) (mode 1) (useauxorigin false) (hpglpennumber 1) (hpglpenspeed 20) (hpglpendiameter 15) (hpglpenoverlay 2) (psnegative false) (psa4output false) (plotreference true) (plotvalue true) (plotothertext true) (plotinvisibletext false) (padsonsilk false) (subtractmaskfromsilk false) (outputformat 1) (mirror false) (drillshape 1) (scaleselection 1) (outputdirectory )) ) (net 0 ) (net_class Default This is the default net class. (clearance 0.254) (trace_width 0.254) (via_dia 0.889) (via_drill 0.635) (uvia_dia 0.508) (uvia_drill 0.127) (add_net ) ) (gr_line (start 232.41 125.73) (end 220.98 125.73) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 232.41 137.16) (end 232.41 125.73) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 220.98 137.16) (end 232.41 137.16) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 220.98 125.73) (end 220.98 137.16) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 160.02 172.72) (end 160.02 119.38) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 160.02 172.72) (end 237.49 172.72) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 237.49 172.72) (end 160.02 172.72) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 237.49 119.38) (end 237.49 172.72) (angle 90) (layer Edge.Cuts) (width 0.15)) (gr_line (start 160.02 119.38) (end 237.49 119.38) (angle 90) (layer Edge.Cuts) (width 0.15)) ) ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
Technically, during the brainstorming process, it is best to gather ideas, and
postpone
passing judgement on those you have already heard, until the evaluation
process, which
comes later. There is a theoretical reason why this is not to be done, and it
supposedly
thwarts creativity.
Creativity is the genesis of good ideas.
After the list of ideas is made, evaluation eventually begins. When it is
agreed that
there are enough ideas to warrant the transition.
So your idea is CPPUnit.
Brainstorming is a fantastic tool, but admittedly it takes some understanding
and
agreement to follow it.
The notion of thwarting creativity is specifically one of the things
brainstorming tries
to avoid, since sometimes the best ideas end up being out of the norm.
Improvements come
by challenging old ways. If they fall into the waste bucket during the
evaluation
process, there is no harm at that point.
Dick
On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
I have the feeling that setting entry points from Python to C, when not
needed will be an
extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or
something that
plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and
calling click
methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check their
correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs
renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to PNG
test theme.
(warning: needs extra maintenance when outputs are enhanced or change, but it
will catch
unexpected changes)
c) Model testing from python, everything that's swigged out can be tested
from there,
and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of
this.
The automated tests I've seen so far (in the last two years) generate an xml
standardized
files (junit xml format) that's used for reports (I use them in bamboo at
nbee, and also
with other client for web ui testing, I've even used it to generate VHDL
testing outputs
from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of
bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es http://www.nbee.es/
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could address a) and b) by having a single DLL/DSO specific entrypoint
for all tests,
with a big switch in there to route to the actual test. This scaffolding
has some
maintenance cost, and begins to wash out the ease of using python on top,
but perhaps not
fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C string
is like a
printf format string.
So it would be possible to make this callable from python and pass all
required arguments
for any worker function. You would have to instantiate the C++ instance
before calling
any member function which is your worker function. But that could be done in
the switch
within the test entrypoint.
test_result TestEntryPoint( aTestNum,
formatStringTellingArgumentTypesInTuple, Tuple )
{
switch( aTestNum )
{
case XYZ:
{
// instantiate what is needed, say obj
// gleen into C++ arguments, those from Tuple by parsing
// formatStringTellingArgumentTypesInTuple
va_args...
// call object member func with C++ form of arguments in tuple.
result = obj-WorkerFunction( arg1, arg2, arg3 );
// destroy what we instantiated.
}
}
return test_result( result ) ; // telling what just happened.
}
The above could be a seed for better ideas. It is a means of testing any
worker
function from python.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
mailto:kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help :
Re: [Kicad-developers] Regression Testing
Miguel,
Sorry, I also was evaluating. So I apologize for being hypocritical on that.
But you'll notice that I was very careful to remain neutral still at this
point, and I was
analyzing mostly my own ideas.
Still, my bad. You see, brainstorming does take some practice :)
I think we'll probably end up with a good solution anyways.
Dick
for sounding On 04/29/2013 11:27 AM, Dick Hollenbeck wrote:
Technically, during the brainstorming process, it is best to gather ideas,
and postpone
passing judgement on those you have already heard, until the evaluation
process, which
comes later. There is a theoretical reason why this is not to be done, and
it supposedly
thwarts creativity.
Creativity is the genesis of good ideas.
After the list of ideas is made, evaluation eventually begins. When it is
agreed that
there are enough ideas to warrant the transition.
So your idea is CPPUnit.
Brainstorming is a fantastic tool, but admittedly it takes some understanding
and
agreement to follow it.
The notion of thwarting creativity is specifically one of the things
brainstorming tries
to avoid, since sometimes the best ideas end up being out of the norm.
Improvements come
by challenging old ways. If they fall into the waste bucket during the
evaluation
process, there is no harm at that point.
Dick
On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
I have the feeling that setting entry points from Python to C, when not
needed will be an
extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or
something that
plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and
calling click
methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check their
correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs
renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to PNG
test theme.
(warning: needs extra maintenance when outputs are enhanced or change, but
it will catch
unexpected changes)
c) Model testing from python, everything that's swigged out can be tested
from there,
and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of
this.
The automated tests I've seen so far (in the last two years) generate an xml
standardized
files (junit xml format) that's used for reports (I use them in bamboo at
nbee, and also
with other client for web ui testing, I've even used it to generate VHDL
testing outputs
from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of
bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es http://www.nbee.es/
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could address a) and b) by having a single DLL/DSO specific entrypoint
for all tests,
with a big switch in there to route to the actual test. This scaffolding
has some
maintenance cost, and begins to wash out the ease of using python on top,
but perhaps not
fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C string
is like a
printf format string.
So it would be possible to make this callable from python and pass all
required arguments
for any worker function. You would have to instantiate the C++ instance
before calling
any member function which is your worker function. But that could be done
in the switch
within the test entrypoint.
test_result TestEntryPoint( aTestNum,
formatStringTellingArgumentTypesInTuple, Tuple )
{
switch( aTestNum )
{
case XYZ:
{
// instantiate what is needed, say obj
// gleen into C++ arguments, those from Tuple by parsing
// formatStringTellingArgumentTypesInTuple
va_args...
// call object member func with C++ form of arguments in tuple.
result = obj-WorkerFunction( arg1, arg2, arg3 );
// destroy what we instantiated.
}
}
return test_result( result ) ; // telling what just happened.
}
The above could be a seed for better ideas. It is a means of testing any
worker
function from python.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to
Re: [Kicad-developers] Regression Testing
Sorry Dick, didn't realize that we were on a brainstorming process, then please
ignore my evaluation to your ideas,
and get my uncreative comments about the standard methods for now.
Will try to be more creative.
Somehow lately I'm forced to stay on more standard methods for a client I work
for, because they always try to stay in standard
methods and systems to reduce maintenance and developer's entry level, but
that's an specific case. I think most of us are
also here for creativity and enjoyment!! ;)
Creativity is good and welcome here! ;)
Miguel Angel Ajo
http://www.nbee.es (http://www.nbee.es/)
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 18:33, Dick Hollenbeck wrote:
Miguel,
Sorry, I also was evaluating. So I apologize for being hypocritical on that.
But you'll notice that I was very careful to remain neutral still at this
point, and I was
analyzing mostly my own ideas.
Still, my bad. You see, brainstorming does take some practice :)
I think we'll probably end up with a good solution anyways.
Dick
for sounding On 04/29/2013 11:27 AM, Dick Hollenbeck wrote:
Technically, during the brainstorming process, it is best to gather ideas,
and postpone
passing judgement on those you have already heard, until the evaluation
process, which
comes later. There is a theoretical reason why this is not to be done, and
it supposedly
thwarts creativity.
Creativity is the genesis of good ideas.
After the list of ideas is made, evaluation eventually begins. When it is
agreed that
there are enough ideas to warrant the transition.
So your idea is CPPUnit.
Brainstorming is a fantastic tool, but admittedly it takes some
understanding and
agreement to follow it.
The notion of thwarting creativity is specifically one of the things
brainstorming tries
to avoid, since sometimes the best ideas end up being out of the norm.
Improvements come
by challenging old ways. If they fall into the waste bucket during the
evaluation
process, there is no harm at that point.
Dick
On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
I have the feeling that setting entry points from Python to C, when not
needed will be an
extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit,
or something that
plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and
calling click
methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check
their correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs
renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to PNG
test theme.
(warning: needs extra maintenance when outputs are enhanced or change,
but it will catch
unexpected changes)
c) Model testing from python, everything that's swigged out can be tested
from there,
and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of
this.
The automated tests I've seen so far (in the last two years) generate an
xml standardized
files (junit xml format) that's used for reports (I use them in bamboo at
nbee, and also
with other client for web ui testing, I've even used it to generate VHDL
testing outputs
from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of
bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es http://www.nbee.es/
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could address a) and b) by having a single DLL/DSO specific
entrypoint for all tests,
with a big switch in there to route to the actual test. This
scaffolding has some
maintenance cost, and begins to wash out the ease of using python on
top, but perhaps not
fully.
In the python C implementation code you find instances of the paradigm
of va_args (tuple)
with a C string telling which argument types are in the tuple. The C
string is like a
printf format string.
So it would be
Re: [Kicad-developers] Regression Testing
If we evaluate cppunit, and run into issues when we try to make it
cross platform, I suggest looking at Google Test Framework, which is
like cppunit, but works better with regards to weird compilers.
Adam Wolf
Wayne and Layne, LLC
On Mon, Apr 29, 2013 at 11:33 AM, Dick Hollenbeck d...@softplc.com wrote:
Miguel,
Sorry, I also was evaluating. So I apologize for being hypocritical on that.
But you'll notice that I was very careful to remain neutral still at this
point, and I was
analyzing mostly my own ideas.
Still, my bad. You see, brainstorming does take some practice :)
I think we'll probably end up with a good solution anyways.
Dick
for sounding On 04/29/2013 11:27 AM, Dick Hollenbeck wrote:
Technically, during the brainstorming process, it is best to gather ideas,
and postpone
passing judgement on those you have already heard, until the evaluation
process, which
comes later. There is a theoretical reason why this is not to be done, and
it supposedly
thwarts creativity.
Creativity is the genesis of good ideas.
After the list of ideas is made, evaluation eventually begins. When it is
agreed that
there are enough ideas to warrant the transition.
So your idea is CPPUnit.
Brainstorming is a fantastic tool, but admittedly it takes some
understanding and
agreement to follow it.
The notion of thwarting creativity is specifically one of the things
brainstorming tries
to avoid, since sometimes the best ideas end up being out of the norm.
Improvements come
by challenging old ways. If they fall into the waste bucket during the
evaluation
process, there is no harm at that point.
Dick
On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
I have the feeling that setting entry points from Python to C, when not
needed will be an
extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or
something that
plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and
calling click
methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check
their correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs
renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to PNG
test theme.
(warning: needs extra maintenance when outputs are enhanced or change, but
it will catch
unexpected changes)
c) Model testing from python, everything that's swigged out can be
tested from there,
and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of
this.
The automated tests I've seen so far (in the last two years) generate an
xml standardized
files (junit xml format) that's used for reports (I use them in bamboo at
nbee, and also
with other client for web ui testing, I've even used it to generate VHDL
testing outputs
from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of
bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es http://www.nbee.es/
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could address a) and b) by having a single DLL/DSO specific entrypoint
for all tests,
with a big switch in there to route to the actual test. This scaffolding
has some
maintenance cost, and begins to wash out the ease of using python on top,
but perhaps not
fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C
string is like a
printf format string.
So it would be possible to make this callable from python and pass all
required arguments
for any worker function. You would have to instantiate the C++ instance
before calling
any member function which is your worker function. But that could be done
in the switch
within the test entrypoint.
test_result TestEntryPoint( aTestNum,
formatStringTellingArgumentTypesInTuple, Tuple )
{
switch( aTestNum )
{
case XYZ:
{
// instantiate what is needed, say obj
// gleen into C++ arguments, those from Tuple by parsing
// formatStringTellingArgumentTypesInTuple
va_args...
// call object member func with C++ form of arguments in tuple.
result = obj-WorkerFunction( arg1, arg2, arg3 );
// destroy what we instantiated.
Re: [Kicad-developers] Regression Testing
On Mon, Apr 29, 2013 at 11:27:57AM -0500, Dick Hollenbeck wrote: So your idea is CPPUnit. CPPUnit seems fine, descending from the old junit framework... from the site seems that the wx support is an addon, not a core feature, so I think it should be experimented on an 'easy' target (like some small dialog). Boost also has a test framework, but I have no idea if it can be coerced to testing wx stuff. Driving the test from the python side seems interesting too, but I don't know if the 'arbitrary call' way works for C++ too (there is name mangling and calling convention in between). Anyway I have no experience whatsoever in automated testing of GUI stuff, so I can't recommend anything else (I mostly do automatic testing of protocols thru the network or serial ports...) -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On Mon, Apr 29, 2013 at 11:38:57AM -0500, Adam Wolf wrote: If we evaluate cppunit, and run into issues when we try to make it cross platform, I suggest looking at Google Test Framework, which is like cppunit, but works better with regards to weird compilers. AFAIK the msvc compiler was ruled out so it's mostly gcc to support (what does osx use? it's gcc even there?) -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
clang for mac osx, but quite compatible. Miguel Angel Ajo http://www.nbee.es (http://www.nbee.es/) +34911407752 skype: ajoajoajo On Monday, 29 de April de 2013 at 18:44, Lorenzo Marcantonio wrote: On Mon, Apr 29, 2013 at 11:38:57AM -0500, Adam Wolf wrote: If we evaluate cppunit, and run into issues when we try to make it cross platform, I suggest looking at Google Test Framework, which is like cppunit, but works better with regards to weird compilers. AFAIK the msvc compiler was ruled out so it's mostly gcc to support (what does osx use? it's gcc even there?) -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] CvPcb footprint filtering.
I've noticed a few bug reports and comments on the developers mailing list recently about the confusing/buggy behavior of the footprint filtering in CvPcb. After using CvPcb while testing my NETLIST_READER changes, I think I understand issue. CvPcb uses three toggle buttons to set the footprint filtering to limit the number of footprints in the footprint list window. One toggle button enables/disables the filtering and the other two allow you to select filter by footprint filters defined in the netlist and the other by the footprint pin count. There does appear to be some buggy (or a least some confusing behavior) with the filtering selection. I propose that the enable/disable button be removed and the two filter type toggle buttons be used to select the filter criteria in a binary logical and fashion. In other words: When both buttons are off, show all footprints. When the filter by netlist filters is on and filter by pin count is off, filter by netlist filters. When the filter by netlist filters is off and filter by pin count is on, filter by pin count. When the filter by netlist filters is on and filter by pin count is on, filter by netlist filters and pin count. One other behavior that might be worth changing is when there are no footprints that meet the filter criteria. The current behavior is to show all of the footprints. This may add to the confusion when the user expects filtering and sees that none of the footprints are filtered rather than an empty footprints list. This makes sense to me. Please let me know if I'm way off base here. If there are not objections, I will add it to my list. Thanks, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] CvPcb footprint filtering.
On Mon, Apr 29, 2013 at 12:57:22PM -0400, Wayne Stambaugh wrote: This makes sense to me. Please let me know if I'm way off base here. If there are not objections, I will add it to my list. Since these are totally independant conditions I think it should work that way. Especially with connector that would be a useful behaviour. -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On 4/29/2013 12:38 PM, Adam Wolf wrote:
If we evaluate cppunit, and run into issues when we try to make it
cross platform, I suggest looking at Google Test Framework, which is
like cppunit, but works better with regards to weird compilers.
Adam Wolf
Wayne and Layne, LLC
If it helps, here is a nice test framework feature comparison chart
(assuming it's correct and reasonably current) for just about every
language.
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
We could always create branch to try different ideas to see what works
and what doesn't before making any decisions. Honestly, I don't have
much experience in this area so I'm going to have to depend on someone
else but I'm willing to do my part as best I can.
Wayne
On Mon, Apr 29, 2013 at 11:33 AM, Dick Hollenbeck d...@softplc.com wrote:
Miguel,
Sorry, I also was evaluating. So I apologize for being hypocritical on that.
But you'll notice that I was very careful to remain neutral still at this
point, and I was
analyzing mostly my own ideas.
Still, my bad. You see, brainstorming does take some practice :)
I think we'll probably end up with a good solution anyways.
Dick
for sounding On 04/29/2013 11:27 AM, Dick Hollenbeck wrote:
Technically, during the brainstorming process, it is best to gather ideas,
and postpone
passing judgement on those you have already heard, until the evaluation
process, which
comes later. There is a theoretical reason why this is not to be done, and
it supposedly
thwarts creativity.
Creativity is the genesis of good ideas.
After the list of ideas is made, evaluation eventually begins. When it is
agreed that
there are enough ideas to warrant the transition.
So your idea is CPPUnit.
Brainstorming is a fantastic tool, but admittedly it takes some
understanding and
agreement to follow it.
The notion of thwarting creativity is specifically one of the things
brainstorming tries
to avoid, since sometimes the best ideas end up being out of the norm.
Improvements come
by challenging old ways. If they fall into the waste bucket during the
evaluation
process, there is no harm at that point.
Dick
On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
I have the feeling that setting entry points from Python to C, when not
needed will be an
extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or
something that
plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and
calling click
methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check
their correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs
renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to
PNG test theme.
(warning: needs extra maintenance when outputs are enhanced or change, but
it will catch
unexpected changes)
c) Model testing from python, everything that's swigged out can be
tested from there,
and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of
this.
The automated tests I've seen so far (in the last two years) generate an
xml standardized
files (junit xml format) that's used for reports (I use them in bamboo at
nbee, and also
with other client for web ui testing, I've even used it to generate VHDL
testing outputs
from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of
bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es http://www.nbee.es/
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could address a) and b) by having a single DLL/DSO specific
entrypoint for all tests,
with a big switch in there to route to the actual test. This scaffolding
has some
maintenance cost, and begins to wash out the ease of using python on
top, but perhaps not
fully.
In the python C implementation code you find instances of the paradigm of
va_args (tuple)
with a C string telling which argument types are in the tuple. The C
string is like a
printf format string.
So it would be possible to make this callable from python and pass all
required arguments
for any worker function. You would have to instantiate the C++ instance
before calling
any member function which is
Re: [Kicad-developers] I hate even more wxString
On Mon, Apr 29, 2013 at 08:40:06AM +0200, Maciej Suminski wrote: I had a similar problem - it was enough to turn off --enable-stl (or explicitly add --disable-stl) for wxWidgets library. Unicode toggling did not change much. Confirmed. It's the --enable-stl that breaks compilation (no idea of why). Maybe we should put a notice for it somewhere in the developers do. Just hope that every distribution build it that way... -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] specctra_export patch to allow nesteted pcb edges
On 04/29/2013 01:22 PM, Dick Hollenbeck wrote:
Thomas,
The keepout polygon you are putting into the DSN file is on a non-existent
layer named
signal.
It seems like a freerouter idiosyncrasy that it accepts this.
Here is the grammar for specctra polygon:
(polygon
layer_id
aperture_width
{vertex }
[(aperture_type [round | square])]
)
Here is what you are outputting:
(keepout (polygon signal 0 220980 -125730 232410 -125730
232410 -137160 220980 -137160 220980 -125730))
1) Do you agree this is probably non-standard behaviour on the part of
freerouter? If
not, can you tell me the page number within the specctra spec where this
single layer
approach is explained?
2) Do you find that although this is only a *single* fictitious layer that
you are
outputting, that the keepout is respected on *all* cu layers within
freerouter?
There were a couple of user's using this export with the Electra router, is
the reason I
ask. It is important to know when we are relying on non-standard behaviour.
Never mind, I found it 12 seconds after I clicked send. Top of page 108.
Cool. So the concept is general, not freerouter specific.
This is making use of a reserved_layer_name which is actually a category
consisting of
all cu layers. Good work.
Thanks,
Dick
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
On Mon, Apr 29, 2013 at 08:08:04PM +0200, Miguel Angel Ajo wrote: KiCad project is full of awesome developers, you go elsewhere proposing unit testing, and you have a 90% chance of hitting people's change rejection…. :) Uhm? Really? Unit testing is a *huge* PITA to set up but in the end it pays back. Especially since the code itself doesn't need to be 'instrumented' for testing usually... i.e. the tests are unobstrusive during development. I didn't think it was so badly seen! It is tricky when you need to test 'hardware' behaviour, like race conditions and nested interrupts. Between two MCUs which have to run in lockstep. And a common watchdog. That's hell:D -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Guidelines for KiROUND-ing
On Mon, Apr 29, 2013 at 07:54:02PM +0200, Heiko Rosemann wrote: It might be in DRC situations - if you want 12mil clearance and calculate a distance of 11.6mil, the rounding will tell you you're fine, the truncation will show you are too close. I agree with you though in that there should be an explicit call to a truncation function (or macro or whatever) for code readability's sake. More or less what I tought too. In fact within the DRC would be safer to err on the other side (i.e. reject a 12.1mil) but that's another story. In fact the 'truncation' is on the nanometer scale, currently so it *shouldn't* give issues, unless for some evil coincidence a rounding bias appears. I'd say that 99% of the times KiROUND is appropriate (unless you want to squeeze a tiny little bit of performance where it is not important, but we're not at this level). -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Guidelines for KiROUND-ing
On Mon, Apr 29, 2013 at 09:03:32PM +0200, Tomasz Wlostowski wrote: My 0.001 cent - It's much simpler: just don't use floating point. That what's we try to do when possible, to avoid rounding issues and have better numerical stability (more or less... I'd like that stability would be achieved only with that!). However there are three important things that need to be done in floating point: - Squaring (not completely sure about this, correct me if I'm wrong), since it exceeds the int dynamic range - Square roots: to find distances and other geometrical stuff. There are integer based square root algorithms (altough not in libm) but the operand is usually the sum of two squares so it doesn't fit an int (see point above). In fact I think the most used libm function (beside the trigs) is hypot. - Trig stuff, for rotation, circles and similar things. Mostly sin/cos and some atan2, too (there is an ArcTangente which works from int values and returns the results in decidegrees; I'm trying to convert the code to use it when possible) I think that circles created with cos/sin should be usually rounded (I don't see any reason to do otherwise), and most distances should, too. Squares are only used as temporary values so they don't give problems (they stay double). So, no, we can't not use a double here... in fact this whole review comes from the angular type becoming a double (before it was an int). Unless you have some magic/clever way to fit these in an int (I don't dare to propose computing distances with a 64 bit integer square root. I've got enough insults for doing this review in the first place :D) Oh well I *could* (the hypot stuff, not the trig one) but then they probably would reject that as some kind of heresy... (also I would need to check the accuracy of such int64 sqrt, many are approximations created for speeding up DSPs) -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Regression Testing
I'm glad that everyone is at least thinking this is a good idea. I know
that it is not an easy thing to get going, and the way we head needs to be
well thought through, so I'd like brainstorming to go on for some more time
so I can get a chance to jot a few more ideas down.
Thanks to everyone for putting up suggestions and support!
Best Regards, Brian.
On 29 April 2013 19:08, Miguel Angel Ajo miguelan...@nbee.es wrote:
KiCad project is full of awesome developers, you go elsewhere proposing
unit testing, and you
have a 90% chance of hitting people's change rejection…. :)
Miguel Angel Ajo
http://www.nbee.es
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 19:10, Wayne Stambaugh wrote:
On 4/29/2013 12:38 PM, Adam Wolf wrote:
If we evaluate cppunit, and run into issues when we try to make it
cross platform, I suggest looking at Google Test Framework, which is
like cppunit, but works better with regards to weird compilers.
Adam Wolf
Wayne and Layne, LLC
If it helps, here is a nice test framework feature comparison chart
(assuming it's correct and reasonably current) for just about every
language.
http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks
We could always create branch to try different ideas to see what works
and what doesn't before making any decisions. Honestly, I don't have
much experience in this area so I'm going to have to depend on someone
else but I'm willing to do my part as best I can.
Wayne
On Mon, Apr 29, 2013 at 11:33 AM, Dick Hollenbeck d...@softplc.com
wrote:
Miguel,
Sorry, I also was evaluating. So I apologize for being hypocritical on
that.
But you'll notice that I was very careful to remain neutral still at this
point, and I was
analyzing mostly my own ideas.
Still, my bad. You see, brainstorming does take some practice :)
I think we'll probably end up with a good solution anyways.
Dick
for sounding On 04/29/2013 11:27 AM, Dick Hollenbeck wrote:
Technically, during the brainstorming process, it is best to gather ideas,
and postpone
passing judgement on those you have already heard, until the evaluation
process, which
comes later. There is a theoretical reason why this is not to be done, and
it supposedly
thwarts creativity.
Creativity is the genesis of good ideas.
After the list of ideas is made, evaluation eventually begins. When it is
agreed that
there are enough ideas to warrant the transition.
So your idea is CPPUnit.
Brainstorming is a fantastic tool, but admittedly it takes some
understanding and
agreement to follow it.
The notion of thwarting creativity is specifically one of the things
brainstorming tries
to avoid, since sometimes the best ideas end up being out of the norm.
Improvements come
by challenging old ways. If they fall into the waste bucket during the
evaluation
process, there is no harm at that point.
Dick
On 04/29/2013 10:40 AM, Miguel Angel Ajo wrote:
I have the feeling that setting entry points from Python to C, when not
needed will be an
extra work and harder to maintain. In that
case why not just using C++ standard testing frameworks?, like CPPUnit, or
something that
plays well with wx for UI testing?
http://wiki.wxwidgets.org/Tools -- Testing
We have two things to test:
1) UI/behaviour , this is usually done launching dialogs manually, and
calling click
methods, reading form entries, checking output, etc…,
Ideally it must be something like (warning, pseudocode)
dialog = MyDialog()
n = dialog-getListElements( 'list1' )
dialog-fillField( 'Field1','Content1' )
dialog-clickButton( 'Add' )
assert dialog-getListElements('list1')==(n+1)
2) Model testing: We call the back models with loads of tests to check
their correct behavior
a) Normal ones, just model behaviour, correct DRC checks,
b) Models that generate outputs: In webkit, they just have pngs of the
outputs
renderings, and they xor/compare. In our case, we can make a diff of
the output contents with expected ones, or try to render them to PNG
test theme.
(warning: needs extra maintenance when outputs are enhanced or change, but
it will catch
unexpected changes)
c) Model testing from python, everything that's swigged out can be tested
from there,
and then we get a contract on what the available methods
are to stay as fixed as possible. Even we get loads of examples out of
this.
The automated tests I've seen so far (in the last two years) generate an
xml standardized
files (junit xml format) that's used for reports (I use them in bamboo at
nbee, and also
with other client for web ui testing, I've even used it to generate VHDL
testing outputs
from ghdl) http://projects.nbee.es:8085/browse/S12-DEF the bad thing of
bamboo is that it
doesn't play well with bzr (AFAIK)
Miguel Angel Ajo
http://www.nbee.es http://www.nbee.es/
+34911407752
skype: ajoajoajo
On Monday, 29 de April de 2013 at 17:06, Dick Hollenbeck wrote:
We could
Re: [Kicad-developers] EESchema - multiple tabbed sheets per design, copy/paste between schematic pages
Hi Travis, I am currently investigating some drawing issues when running under OSX. I'm in a very early phase of the investigation, but I'm trying to figure out: 1. why the component (when dragged or moved) steps aside a little bit, just to step when one places it 2. why the menubars disappear when moving a part (they don't do it when one drags the component) 3. what the differences are between the moving and dragging drawing code. so I think we could have a chat about this stuff :) Greets, Felix Am 29.04.2013 um 17:38 schrieb Travis Ayres tray...@gmail.com: Hi all, I'd like to understand where the development of EESchema is, because I'd like tabs for each page of a design and the ability to copy/paste between schematics. Also, I have found a few redraw issues (that I haven't looked into yet). Is there anyone who's working on something similar or someone who's thinking about the same thing I could start a conversation with to improve EESchema? Thanks, -Travis ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Guidelines for KiROUND-ing
On 04/29/2013 09:51 PM, Lorenzo Marcantonio wrote: On Mon, Apr 29, 2013 at 09:03:32PM +0200, Tomasz Wlostowski wrote: My 0.001 cent - It's much simpler: just don't use floating point. That what's we try to do when possible, to avoid rounding issues and have better numerical stability (more or less... I'd like that stability would be achieved only with that!). Hi Lorenzo, This is what we're trying to do in the Geometry Library. It's fixed-point only (and I hope we'll be able to check distances/clearance of arcs without FP calculations either or without numeric stability issues). The biggest problem I've encountered with FP calculations is that an intersection point of two segments derived with one algorithm may not be qualified as being exactly on that segment by another routine (and as a result, the PS algorithm will go crazy...). So the PS code doesn't use floats at all. And I'm happy with this. However there are three important things that need to be done in floating point: - Squaring (not completely sure about this, correct me if I'm wrong), since it exceeds the int dynamic range (Int32_t * int32_t) fits in uint64_t (that is, VECTOR2int::ecoord_type to make things look cleaner). - Square roots: to find distances and other geometrical stuff. Compare squared distances... - Trig stuff, for rotation, circles and similar things. Mostly sin/cos and some atan2, too (there is an ArcTangente which works from int values and returns the results in decidegrees; I'm trying to convert the code to use it when possible) This is the tricky part. In case of PS, it doesn't care about rotation and treats rotated objects as convex polygons. Whatever trigonometric, FP operations are required to generate their shapes, they are kept outside. I guess the same rule could be applied to future versions of DRC. BTW. I noticed that TestForIntersectionOfStraightLineSegments() function that is used in the DRC will very likely cause false DRC errors when used with PS. It uses y=mx+b line equation, with a numerically unstable division to calculate the slope m (that may result with large rounding error, above DRC tollerance - to be verified). So, no, we can't not use a double here... in fact this whole review comes from the angular type becoming a double (before it was an int). Unless you have some magic/clever way to fit these in an int (I don't dare to propose computing distances with a 64 bit integer square root. Why not, what's wrong about this? I'm even using 96-bit operations for accurate intersection point computation, but this magic is hidden from the user. The simply returns the a VECTOR2T, whatever the type T is. Casting ints to doubles and back to ints simply doesn't work in my case. Regards, Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Highlithing components with a certain value
Hi Piotr (and others) please find the patch attached, as requested. I've redesigned the find dialog a bit and removed the find next marker in the DRC dialog again, as I found it's not necessery, as on the same dialog, there is the list of markers available. Have fun Simon -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Sunday, April 28, 2013 11:57 AM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value I have only now noticed that naming the checkbox mark all components is not so good because there is a button called find marker, and here, marker means something completely different (DRC marker) But I think, the find dialog is not a good place for this. Yes, I want to find a marker. But, as far I can see, this button only finds the next marker, and the search field is ignored. So, it's not a ctrl-f function at all. Ok, here's what I suggest: - Move this function to the DCR dialog. Honestly, this is where you would suppose the button that shows you the next DRC marker. And it's near the remove all markers then. - add a button to the find dialog saying remove all marks - maybe find a new word for mark for this purpose we are discussing about here that is not so near the DRC marker. highligtht? I still think, just highlighting is not enough... This way, everything is where you would expect it. -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 11:46 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value Ok, I was experimenting a little bit. Please see the attached picture. I searched for all components valued with 470 and afterwards supp40. As the marks are not (yet) removed before a new search, you can see both results. The highlighting alone is only visible in high contrast mode. Maybe I did something wrong. But nevertheless, I like the circles. They are very well visible also for small components and show well, where the component is (in the center of the circle. I just decided to set the radius to the arithmetic mean of the x- and y size of the bounding box. Of course, the shape as well as the size can still be optimized. BTW: due to these circles, I named the checkbox mark all matches instead of highlight all matches. What do you think? And then: How do we get rid of the marks again? A button named unmark all? Where? On the search dialog? I have no clue at the moment... -Ursprüngliche Nachricht- From: Simon Huwyler Sent: Saturday, April 27, 2013 6:44 PM To: Lorenzo Marcantonio ; Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value I don't know. That's why I wanted to experimen. I don't know if you cann see a 0603 footprint on a 100mmx100mm board, if it's highlighted. Maybe yes, then it's fine. But I just looked at a highlighted net. It's perfect for showing a net, but I think, if it was only a tiny 0603 footprint, I would hardly see it. -Ursprüngliche Nachricht- From: Lorenzo Marcantonio Sent: Saturday, April 27, 2013 6:40 PM To: Kicad Developers Subject: Re: [Kicad-developers] Highlithing components with a certain value On Sat, Apr 27, 2013 at 06:30:47PM +0200, Simon Huwyler wrote: board. Maybe something completely differen would be better? A circle around the component? ... what do you think? We already have highlighting code *and* the extended palette to support it. Why invent something else? -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp find_and_mark_items.patch Description: Binary data ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Guidelines for KiROUND-ing
On Tue, Apr 30, 2013 at 12:28:56AM +0200, Tomasz Wlostowski wrote: - Squaring (not completely sure about this, correct me if I'm wrong), since it exceeds the int dynamic range (Int32_t * int32_t) fits in uint64_t (that is, VECTOR2int::ecoord_type to make things look cleaner). Look, I have this 'political' situation here: I added a typedef for the layer identifier (search for the LAYER_NUM) to better identify it and be ready for whatever thing we decide to use when we add more layers. I almost got lynched since they said 'int is more legible' (LAYER was already taken:P) - Square roots: to find distances and other geometrical stuff. Compare squared distances... Well, when I need a radius to draw I have to root it :D however even a simple Newton convergence would do the trick in many many places, without the tricks used for DSP (or maybe the DSP rooter is in fact accurate:P). It's also needed for the vector norm (used when projecting, for example). It's difficult to do linear algebra without sqrt:D This is the tricky part. In case of PS, it doesn't care about rotation and treats rotated objects as convex polygons. Whatever trigonometric, FP operations are required to generate their shapes, they are kept outside. I guess the same rule could be applied to future versions of DRC. Well... it's not exactly the last trend but... have you tried CORDIC? I don't *actually* get the math behind, but should work. Also, in fact, everything we need is a sin/cos for the unity circle and atan2 for measuring angles. Hey, it even has a square root:D Sadly the most common case (45 degrees!) has the dreaded sqrt(2) creeping in (so even with fixed point manipulation has to be kept to a minimum). BTW. I noticed that TestForIntersectionOfStraightLineSegments() function that is used in the DRC will very likely cause false DRC errors when used with PS. It uses y=mx+b line equation, with a numerically unstable division to calculate the slope m (that may result with large rounding error, above DRC tollerance - to be verified). These functions have other issues too. For example one of the intersection (I don't remember if it's the same you said) computes a lot of stuff (included distances) even if not requested to. In fact come out at 22% time in a redisplay profiling. The funny thing is that elsewhere probably there is another intersection done in a saner way. Unless you have some magic/clever way to fit these in an int (I don't dare to propose computing distances with a 64 bit integer square root. Why not, what's wrong about this? I'm even using 96-bit operations for accurate intersection point computation, but this magic is hidden from the user. The simply returns the a VECTOR2T, whatever the type T is. Casting ints to doubles and back to ints simply doesn't work in my case. For someone in there that's 'bullshit'. They changed the angles to double but don't care (at the moment) to check if they are stuffed to int and back elsewhere (which they do, even in the DRC). Not to mention some places where it goes from radians (from atan2) to decidegrees (in an int) and back to radians for a rotation. And it's all done with wxPoint so no serious vector work for you (also a huge work if it would to change). Also, it seems that apparently I'm not qualified for a code review or touching things that 'already work'... what appreciation :D -- Lorenzo Marcantonio Logos Srl ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] EESchema - multiple tabbed sheets per design, copy/paste between schematic pages
I have noticed another issue - when I place the cursor near the edge of the screen, then use a arrow key to move a screenful, there is a residue left on the screen from the cursor. On Apr 29, 2013 3:02 PM, Felix Morgner felix.morg...@gmail.com wrote: Hi Travis, I am currently investigating some drawing issues when running under OSX. I'm in a very early phase of the investigation, but I'm trying to figure out: 1. why the component (when dragged or moved) steps aside a little bit, just to step when one places it 2. why the menubars disappear when moving a part (they don't do it when one drags the component) 3. what the differences are between the moving and dragging drawing code. so I think we could have a chat about this stuff :) Greets, Felix Am 29.04.2013 um 17:38 schrieb Travis Ayres tray...@gmail.com: Hi all, I'd like to understand where the development of EESchema is, because I'd like tabs for each page of a design and the ability to copy/paste between schematics. Also, I have found a few redraw issues (that I haven't looked into yet). Is there anyone who's working on something similar or someone who's thinking about the same thing I could start a conversation with to improve EESchema? Thanks, -Travis ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
