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 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 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 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. -- 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 Sun, Apr 28, 2013 at 11:19:02PM -0500, Dick Hollenbeck wrote: > Can you name the class where setangle, the interface, cannot successfully > set an angle of any degree, without talking about client code? No, I didn't look for it, but the compiler flagged that (innocuous) swap so there *could* be others, but *proving* that would be difficult. Also it's a moot point if *some* implementation inside truncates it to an int. That is what I meant. In some embedded application such kind of analysis is mandated so I'm pretty paranoid about it (there are extremes too: in MISRA C you *can't* use pointers at all to avoid indirection errors; good luck passing parameters out from functions) You can talk about interfaces and implementation as much as you want, but if the code is wrong, is wrong:P In fact I think that hiding too much behind an interface is dangerous *unless* it's so detailed that no other implementation could implement it (happened to me, wasn't fun when they changed the implementation). In short the black block approach simply don't work (it's not useless, but it can't be trusted). In fact, even if a dialog box doesn't accept a double (hypotetical, since they already have to multiply by 10) your interface would be fine but the *specification* (i.e. assigning a double to an angle) wouldn't be met. Some could even argue that not accepting the second digit would be a breach of specification, too (but, again, if there is no rounding in the dialog code there shouldn't be any problem). If you care so much about your interface the do programming by contract. But then we decided to not overassert. In this particular case probably most of the times angles are just passed around or converted to radiants for trig so it's probably all OK; in fact probably the only bug that could pop from this type change is a rounding to one decidegree. That said, I think that knowing that "angles in kicad are doubles expressed as decidegrees" is a pretty important thing to know (especially before it was "angles in kicad are ints expressed as decidegrees"). That was the spirit of the question. -- 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 Apr 28, 2013 11:19 PM, "Dick Hollenbeck" wrote: > > > On Apr 28, 2013 11:09 PM, "Lorenzo Marcantonio" < l.marcanto...@logossrl.com> wrote: > > > > On Sun, Apr 28, 2013 at 03:50:09PM -0500, Dick Hollenbeck wrote: > > > The interface is correct. Setting any angle is desired. The implentation > > > is insufficient in this case. The black box is broken and needs > > > embellishment. > > > > > > I chose what the dog is to do when we started the plugins. The tail is not > > > wagging properly yet. > > > > More strange metaphors:D > > > > Anyway, I think I got the meaning. The right type to use for the angle > > is double and the decidegrees are a legacy from when it was an int. > > > > Finding the remaining 'int angles' (i.e. fixing the box) sadly will not > > be very easy... > > I think we are talking past each other. Not communicating. > > There are 3 things: client code, interface, and implementation. 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. > Can you name the class where setangle, the interface, cannot successfully set an angle of any degree, without talking about client code? > > > > > -- > > 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] Miscellaneous stuff
On Apr 28, 2013 11:09 PM, "Lorenzo Marcantonio" wrote: > > On Sun, Apr 28, 2013 at 03:50:09PM -0500, Dick Hollenbeck wrote: > > The interface is correct. Setting any angle is desired. The implentation > > is insufficient in this case. The black box is broken and needs > > embellishment. > > > > I chose what the dog is to do when we started the plugins. The tail is not > > wagging properly yet. > > More strange metaphors:D > > Anyway, I think I got the meaning. The right type to use for the angle > is double and the decidegrees are a legacy from when it was an int. > > Finding the remaining 'int angles' (i.e. fixing the box) sadly will not > be very easy... I think we are talking past each other. Not communicating. There are 3 things: client code, interface, and implementation. Can you name the class where setangle, the interface, cannot successfully set an angle of any degree, without talking about client code? > > -- > 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] Miscellaneous stuff
On Sun, Apr 28, 2013 at 03:50:09PM -0500, Dick Hollenbeck wrote: > The interface is correct. Setting any angle is desired. The implentation > is insufficient in this case. The black box is broken and needs > embellishment. > > I chose what the dog is to do when we started the plugins. The tail is not > wagging properly yet. More strange metaphors:D Anyway, I think I got the meaning. The right type to use for the angle is double and the decidegrees are a legacy from when it was an int. Finding the remaining 'int angles' (i.e. fixing the box) sadly will not be very easy... -- 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
The other thing I learned was that python can call arbitrary C functions in an arbitrary dll, even if they are not swigged. Sure, ctypes is, IMHO, one of the coolest standard library modules. ___ 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 28, 2013 10:54 AM, "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. > 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. > 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
Re: [Kicad-developers] Regression Testing
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 (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 > (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] Miscellaneous stuff
. On Apr 28, 2013 8:31 AM, "Lorenzo Marcantonio" wrote: > > On Sun, Apr 28, 2013 at 08:09:29AM -0500, Dick Hollenbeck wrote: > > GenDate() is not my function, so I could only offer an opinion but no protective mandate. > > I am neutral, and to formulate a strong opinion would require a study of its usage, for > > which I do not have the time. > > AFAIK mostly reports and sheet border. I'll investigate. > > > std::swap seems OK, but it may cost us compile time by bringing in a header or two > > everywhere. Your template is also OK and perhaps leaner to compile. Either is superior > > to the macro. > > std::swap wouldn't work since there are (harmless) cases in which an int > is swapped with a double. The real question is why degrees are stored as > double and not as int when they are defined in tenth of degree. Interfaces are the dog, implementations are the tail. The dog wags the tail, not the other way around. The interface is correct. Setting any angle is desired. The implentation is insufficient in this case. The black box is broken and needs embellishment. I chose what the dog is to do when we started the plugins. The tail is not wagging properly yet. > std::swap is nearly identical to mine, it only has one template > parameter. Also it has been relocated (from algorithm to utility) in > C++11 so it can give compilation issues. > > > Reasoning: we can at least see what is happening. SAFE_DELETE tells me absolutely > > nothing, other than that my normal delete is not safe, and that is hogwash. > > More or less agree with that. I guess it's the idiom for garbage > collected languages to set the reference to nil and send the object to > its death. Need investigations (I think that's probably used not many > times). > > > If there is not way to Set the LayerPair, then LayerPair() would also be OK for me. > > There is a SetLayerPair, in fact these are the only members using it:P > No problem with Returnxxx, only consistency. > > > This is code that I have worked on, don't recall who originally wrote it. If the > > interface is well defined and the contract of the interface is being met, then I would say > > leave the black box implementation alone, until it stops working. > > It's a getter and a setter only, but it breaks the idea of layer identifier. In fact in the whole hierarchy the m_layer contains *the* layer, with the via it contains *stuff*. In the '60 with 36 bit word architectures maybe that was the best thing to do but here it only break a 'type' (for about 4 bytes:D). Anyway I'll keep it here, now it don't harm anyone. > > > // when 7000 stops working, ask dick > > OK, it's real magic then > > > Yes, if that's what the UI guidelines call for, go for it. > > Not guidelines, it more spelling... SMD is an acronym so it should be > upcased. Like OK. > > -- > 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] Miscellaneous stuff
On 4/28/2013 7:41 AM, Lorenzo Marcantonio wrote:
I was comparing my tree with the master one. These are some changes
I did in times and I would like what do you think of these
- GenDate() at the moment uses a fixed format (more or less the european
one), with the months hardcoded to the short english names.
Wouldn't it be better to use the localised formatter? I'm using
"%e %B %Y" but even better would be the strftime %x formatter
Make sure none of the file readers are parsing dates generated by
GenDate(). Otherwise, files may not be readable between locales.
- In the grid drawing code there is a special case to show
a double-pitch grid before suppressing the drawing. That's confusing
if you're using the grid to estimate distances. So if the grid doesn't
fit, just hide it
- Many of the macros in macros.h would be better defined as templated
functions (unless there is some weird preference for macrofunctions in
C++). In particular EXCHG wouldn't need the boost typeof machinery.
It's pretty simple, actually:
template inline void EXCHG( T& a, T2& b )
{
T temp = a;
a = b;
b = temp;
}
A similar approach holds for the other ones. If it wasn't for some
mixed-type usage (double with int, for angles, IIRC), std::swap would
be even better.
- The same hold for SAFE_DELETE; the current one in particular is *not*
protected against accidental single-statement use i.e.
if (stuff) SAFE_DELETE(x);
generates the equivalent
if (stuff) delete x;
x = NULL;
which is clearly wrong; if (for some unknown reason) a macro is
preferred at least we should add a do { ... } while (0) guard
- ReturnLayerPair is a strange name for an accessor... I propose to
rename it to GetLayerPair (IIRC it already happened int the past)
- I have 'split' the two layer in a via adding a bottomlayer member
instead of that nasty hack of bit-encoding them in the primary layer.
It only accessor-used but it's ugly (it will come back if someone
subclasses the via class, anyway)
- Question: is 7000 a magic number for a layer in specctra_import?
a define or at least a comment would be useful.
- In the tooltips inside dialog_edit_module_for_Modedit.cpp smd should
be uppercased :D
Other layer stuff is in standby until we decide what to do (i.e.
probably until we have the new library format working)
___
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 28/04/2013 13:41, Lorenzo Marcantonio a écrit :
I was comparing my tree with the master one. These are some changes
I did in times and I would like what do you think of these
- GenDate() at the moment uses a fixed format (more or less the european
one), with the months hardcoded to the short english names.
Wouldn't it be better to use the localised formatter? I'm using
"%e %B %Y" but even better would be the strftime %x formatter
- In the grid drawing code there is a special case to show
a double-pitch grid before suppressing the drawing. That's confusing
if you're using the grid to estimate distances. So if the grid doesn't
fit, just hide it
I disagree: a grid with a double pitch is still useful, when you need a
grid.
To estimate distances there are (by far) better ways than count grid points.
- Many of the macros in macros.h would be better defined as templated
functions (unless there is some weird preference for macrofunctions in
C++). In particular EXCHG wouldn't need the boost typeof machinery.
It's pretty simple, actually:
template inline void EXCHG( T& a, T2& b )
{
T temp = a;
a = b;
b = temp;
}
A similar approach holds for the other ones. If it wasn't for some
mixed-type usage (double with int, for angles, IIRC), std::swap would
be even better.
Agreed.
- The same hold for SAFE_DELETE; the current one in particular is *not*
protected against accidental single-statement use i.e.
if (stuff) SAFE_DELETE(x);
generates the equivalent
if (stuff) delete x;
x = NULL;
which is clearly wrong; if (for some unknown reason) a macro is
preferred at least we should add a do { ... } while (0) guard
As far I remember, it was already pointed out. But the fix was never made.
This is good to fix it.
- ReturnLayerPair is a strange name for an accessor... I propose to
rename it to GetLayerPair (IIRC it already happened int the past)
- I have 'split' the two layer in a via adding a bottomlayer member
instead of that nasty hack of bit-encoding them in the primary layer.
It only accessor-used but it's ugly (it will come back if someone
subclasses the via class, anyway)
- Question: is 7000 a magic number for a layer in specctra_import?
a define or at least a comment would be useful.
- In the tooltips inside dialog_edit_module_for_Modedit.cpp smd should
be uppercased :D
Other layer stuff is in standby until we decide what to do (i.e.
probably until we have the new library format working)
--
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] Proposal: Move to C++11
Le 27/04/2013 18:42, Lorenzo Marcantonio a écrit : On Sat, Apr 27, 2013 at 12:31:54PM -0400, Wayne Stambaugh wrote: GCC 4.8 is fully 0x11 compliant with one minor exception (see the Have they fixed the misoptimization breaking the zone filling code at least? About zone filling code and boost polygon issues see: https://svn.boost.org/trac/boost/ticket/7983 closed but not fixed. and (by far most annoying) https://svn.boost.org/trac/boost/ticket/7984 not fixed. Don't forget about compiler maturity... 4.8 is like only one month old. -- 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
[Kicad-developers] I hate even more wxString
Every wx releases something works slightly different...
I'm trying to use wx 2.9.4 (installed with the wxPython distribution)
Configured OK, building woes:
static int wxCALLBACK MyCompareFunction( long aItem1, long aItem2, long
aSortData )
{
wxString* component1Name = (wxString*) aItem1;
wxString* component2Name = (wxString*) aItem2;
return StrNumCmp( *component1Name, *component2Name,
INT_MAX, true );
}
StrNumCmp takes two const wxChar* so I presume the idea was to use some kind of
internal autoconversion of wxString to const wxChar* (I don't know if it
exists... where it a std::string you would have to use c_str() or similar).
However g++ spit out this:
error: cannot convert 'wxString' to 'const wxChar* {aka const wchar_t*}' for
argument '1' to 'int StrNumCmp(const wxChar*, const wxChar*, int, bool)'
... 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???
Another 'funny' thing: I have in my text drawing routine used the '\' character
to do an escape to the Technical Set 1. So I have an int called escape_base
containing the offset if the escape is in effect. The incriminated line is:
AsciiCode = aText.GetChar( ptr ) + escape_base;
AsciiCode is an int too, BTW. In its holyness g++ complains:
error: ambiguous overload for 'operator+' in '(&
aText)->wxString::GetChar(((size_t)ptr)) + escape_base
So we have a wxUniChar (in 2.9 it's a class!) and an int. However the rules for
conversion are... uhm... involved... so there are 18 (EIGHTEEN) fscking
operator + to choose from... so I need to 'clarify' using
int(aText.GetChar(ptr))
Hate hate hate
Does it happen only to me???
--
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 Sun, Apr 28, 2013 at 03:33:32PM +0200, Lorenzo Marcantonio wrote:
> AFAIK mostly reports and sheet border. I'll investigate.
Correction, it's *only* for the title block. The default ("%x")
formatting (for the italian locale, at least) is numeric only
(like dd/mm/) so it's *very* easy to interpret it correctly when
there is doubt on the format (the american mm/dd/ can't often be
distingueshed correctly).
There *is* a locale function to get the preferred long date format but
it's for wx 2.9 and later only. How distressful...
AFAIK we are still targeting wx 2.8 minimum, right?
Oh well, that's not important, it stay as it's now, for the moment...
--
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
[Kicad-developers] Regression Testing
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
Re: [Kicad-developers] Miscellaneous stuff
On Sun, Apr 28, 2013 at 08:09:29AM -0500, Dick Hollenbeck wrote: > GenDate() is not my function, so I could only offer an opinion but no > protective mandate. > I am neutral, and to formulate a strong opinion would require a study of its > usage, for > which I do not have the time. AFAIK mostly reports and sheet border. I'll investigate. > std::swap seems OK, but it may cost us compile time by bringing in a header > or two > everywhere. Your template is also OK and perhaps leaner to compile. Either > is superior > to the macro. std::swap wouldn't work since there are (harmless) cases in which an int is swapped with a double. The real question is why degrees are stored as double and not as int when they are defined in tenth of degree. BTW std::swap is nearly identical to mine, it only has one template parameter. Also it has been relocated (from algorithm to utility) in C++11 so it can give compilation issues. > Reasoning: we can at least see what is happening. SAFE_DELETE tells me > absolutely > nothing, other than that my normal delete is not safe, and that is hogwash. More or less agree with that. I guess it's the idiom for garbage collected languages to set the reference to nil and send the object to its death. Need investigations (I think that's probably used not many times). > If there is not way to Set the LayerPair, then LayerPair() would also be OK > for me. There is a SetLayerPair, in fact these are the only members using it:P No problem with Returnxxx, only consistency. > This is code that I have worked on, don't recall who originally wrote it. If > the > interface is well defined and the contract of the interface is being met, > then I would say > leave the black box implementation alone, until it stops working. It's a getter and a setter only, but it breaks the idea of layer identifier. In fact in the whole hierarchy the m_layer contains *the* layer, with the via it contains *stuff*. In the '60 with 36 bit word architectures maybe that was the best thing to do but here it only break a 'type' (for about 4 bytes:D). Anyway I'll keep it here, now it don't harm anyone. > // when 7000 stops working, ask dick OK, it's real magic then > Yes, if that's what the UI guidelines call for, go for it. Not guidelines, it more spelling... SMD is an acronym so it should be upcased. Like OK. -- 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] layer based constraints
On 04/27/2013 12:10 PM, Lorenzo Marcantonio wrote: > On Sat, Apr 27, 2013 at 11:11:54AM -0500, Dick Hollenbeck wrote: >> But how important is that really? Will it result in a reduction in pay? >> >> The "common" user has been a hobbyist, and is becoming a corporate employee >> as the >> software gets better. > > OK, even most of the corporate employees have probably 0% of > understanding a boolean expression. Unless he's a digital designer :D > woes on him in that case > >> So while I agree, I think the importance of this concern is minimal. >> Actually zero. >> If we like it, that should be good enough. We are corporate employees, and >> are paying to >> make this software useable for our needs. You said yourself the same thing. > > Agree on that. But if it's possible to make it usable for the > non-programmer people (without too much work) then it's better. > Otherwise I'd looking for components using grep instead of the component > browser for example (the sad thing is that often grepping is more > effective...) > >> Great idea, do it. It seems we are all still open to the best ideas. > > In a previous message I wrote about how CAM350/gerbtool do DRC. The CAM > products are for 60% DRC beasts so they know how to do their job:D > > Eagle has a simple netclass-to-netclass clearance. I haven't used any > other of the 'big ones' (Altium, Allegro, PADS or Expedition) so I don't > really know how they handle it. Many entry level products don't have even > a netclass notion, so we already are way above them:D > >> Is there a way we can provide a python expression, but do most of the work >> in C++?, by >> implementing the functions being called in C++ behind the expression, by >> following the >> python C API. >> >> This is a slight variation on the original idea, which can be a way to turbo >> charge it, >> maybe to cut out a few lookups at runtime. >> >> Obviously the python expressions can all be "pre-compiled", but I don't >> think they can be >> "pre-evalutated" when "both" is in play, since that is a dynamic match maker. > > Caching (memoizing, actually) strategies for the python calls would > depend on the data available to the call. Assuming the function is pure > (i.e. depending only on the passed parameters) you could cull *a lot* of > calls. > > Example (in C, I don't know python enough): function returning > the clearance (one of the contended values) between two netclasses and > the current layer; with only the minimum data we'd have: > > int dynamic_clearance(const char *netclass1, const char *netclass2, > const char *layer); > > *iif* the implementation is pure, as from the hypothesis, there are no > external dependancies and no collateral effects so *every* call with > a tuple (triplet) would always return the same value. Put it in a map > (memoize it) and you have just resolved the clearance issues between > these two classes on that layer with just one python call. AFAIK > memoizing is a standard idiom in python, too. > > More flexibility reduces optimization possibilities. Let's say we pass > the netnames too (don't ask why, maybe the user wants more granularity > than netnames, no idea) > > int dynamic_clearance(const char *netclass1, const char *netclass2, > const char *netname1, const char *netname2, > const char *layer); > > Here memoizing is a lot less effective... you only cache clearance > between two nets (the netclasses are actually redundant and passed as > convenience). However you would optimize the common case of buses > wandering around the board. Still a good improvement, probably. > > At the other end, if the decision function has the whole segment > information at hand: > > int dynamic_clearance(const char *netclass1, const char *netclass2, > const char *netname1, const char *netname2, > const char *layer, int stuff, int other_stuff...) > > Then we gain *no* performance since (ideally) every segment is tested > against any other segment just once. In fact caching overhead would > probably make it slower than without. > > That said, maybe a python call is just so fast that the big time is > spent computing distances maybe. Or the bottleneck is in the string > comparison. If it was LUA instead of Python I'd say to directly call the > function without any doubt (LUA strings are interned so the string > equality is pointer equality for example, and the byte code interpreter > is... well, fast). > > As you said instrumented profiling is needed, at least to compare the cost > of a python call to the rest of the stuff in the DRC routines. Caching is an interesting idea to keep in our toolbox. I think C++ has some great potential in developing some wrapper classes for making use of python expessions fairly painless. It is an area I hope to contribute to when I have some more time. Each year we host a large memorial day party here at the
Re: [Kicad-developers] Miscellaneous stuff
On 04/28/2013 06:41 AM, Lorenzo Marcantonio wrote:
> I was comparing my tree with the master one. These are some changes
> I did in times and I would like what do you think of these
>
> - GenDate() at the moment uses a fixed format (more or less the european
> one), with the months hardcoded to the short english names.
GenDate() is not my function, so I could only offer an opinion but no
protective mandate.
I am neutral, and to formulate a strong opinion would require a study of its
usage, for
which I do not have the time.
>
> Wouldn't it be better to use the localised formatter? I'm using
> "%e %B %Y" but even better would be the strftime %x formatter
>
> - In the grid drawing code there is a special case to show
> a double-pitch grid before suppressing the drawing. That's confusing
> if you're using the grid to estimate distances. So if the grid doesn't
> fit, just hide it
Mildly in favor of your argument.
>
> - Many of the macros in macros.h would be better defined as templated
> functions (unless there is some weird preference for macrofunctions in
> C++). In particular EXCHG wouldn't need the boost typeof machinery.
> It's pretty simple, actually:
>
> template inline void EXCHG( T& a, T2& b )
> {
> T temp = a;
> a = b;
> b = temp;
> }
>
> A similar approach holds for the other ones. If it wasn't for some
> mixed-type usage (double with int, for angles, IIRC), std::swap would
> be even better.
std::swap seems OK, but it may cost us compile time by bringing in a header or
two
everywhere. Your template is also OK and perhaps leaner to compile. Either is
superior
to the macro.
>
> - The same hold for SAFE_DELETE; the current one in particular is *not*
> protected against accidental single-statement use i.e.
>
> if (stuff) SAFE_DELETE(x);
>
> generates the equivalent
>
> if (stuff) delete x;
> x = NULL;
SAFE_DELETE is not my code. But I do not like it in any fashion.
I would rather see it removed in total.
SAFE_DELETE( p );
replaced with:
delete p;
D( p = 0 ); // if the null is needed at all
Reasoning: we can at least see what is happening. SAFE_DELETE tells me
absolutely
nothing, other than that my normal delete is not safe, and that is hogwash.
A C++ programmer should know that
OBJ* p = NULL;
delete p;
is harmless.
>
> which is clearly wrong; if (for some unknown reason) a macro is
> preferred at least we should add a do { ... } while (0) guard
>
> - ReturnLayerPair is a strange name for an accessor... I propose to
> rename it to GetLayerPair (IIRC it already happened int the past)
This is not my code, JP should have final say.
In general when there is both a setter and getter accessor, I tend to go with
Get..() and
Set..(). But when there is only a getter, I often prefer to leave off the
Get..() prefix.
CurLineNumber() is an example in DSN_LEXER. So this is a preference in my
code. No
setter is pertinent, so the getter drops the Get. There is nothing sacred
about Set and
Get, other than that we've achieved some consistency.
If there is not way to Set the LayerPair, then LayerPair() would also be OK for
me.
>
> - I have 'split' the two layer in a via adding a bottomlayer member
> instead of that nasty hack of bit-encoding them in the primary layer.
> It only accessor-used but it's ugly (it will come back if someone
> subclasses the via class, anyway)
This is code that I have worked on, don't recall who originally wrote it. If
the
interface is well defined and the contract of the interface is being met, then
I would say
leave the black box implementation alone, until it stops working.
>
> - Question: is 7000 a magic number for a layer in specctra_import?
> a define or at least a comment would be useful.
add this:
// when 7000 stops working, ask dick
>
> - In the tooltips inside dialog_edit_module_for_Modedit.cpp smd should
> be uppercased :D
Yes, if that's what the UI guidelines call for, go for it.
>
> Other layer stuff is in standby until we decide what to do (i.e.
> probably until we have the new library format working)
>
___
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] Miscellaneous stuff
I was comparing my tree with the master one. These are some changes
I did in times and I would like what do you think of these
- GenDate() at the moment uses a fixed format (more or less the european
one), with the months hardcoded to the short english names.
Wouldn't it be better to use the localised formatter? I'm using
"%e %B %Y" but even better would be the strftime %x formatter
- In the grid drawing code there is a special case to show
a double-pitch grid before suppressing the drawing. That's confusing
if you're using the grid to estimate distances. So if the grid doesn't
fit, just hide it
- Many of the macros in macros.h would be better defined as templated
functions (unless there is some weird preference for macrofunctions in
C++). In particular EXCHG wouldn't need the boost typeof machinery.
It's pretty simple, actually:
template inline void EXCHG( T& a, T2& b )
{
T temp = a;
a = b;
b = temp;
}
A similar approach holds for the other ones. If it wasn't for some
mixed-type usage (double with int, for angles, IIRC), std::swap would
be even better.
- The same hold for SAFE_DELETE; the current one in particular is *not*
protected against accidental single-statement use i.e.
if (stuff) SAFE_DELETE(x);
generates the equivalent
if (stuff) delete x;
x = NULL;
which is clearly wrong; if (for some unknown reason) a macro is
preferred at least we should add a do { ... } while (0) guard
- ReturnLayerPair is a strange name for an accessor... I propose to
rename it to GetLayerPair (IIRC it already happened int the past)
- I have 'split' the two layer in a via adding a bottomlayer member
instead of that nasty hack of bit-encoding them in the primary layer.
It only accessor-used but it's ugly (it will come back if someone
subclasses the via class, anyway)
- Question: is 7000 a magic number for a layer in specctra_import?
a define or at least a comment would be useful.
- In the tooltips inside dialog_edit_module_for_Modedit.cpp smd should
be uppercased :D
Other layer stuff is in standby until we decide what to do (i.e.
probably until we have the new library format working)
--
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] 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
