← Back to team overview

kicad-developers team mailing list archive

Re: Concerns about clearing disagreements before committing.



Well, this is a good example for you.  Go look at what has to be
changed to change the trig functions to use, errr, libm!  They
are called from all over hades' half-acre, always from outside
the object, always directly accessing members of the objects,
some places applying one round-off; some places, another; some
places making one assumption about round-off; another place,
another assumption; always outside the object.

With a proper OO design, these trig functions would have been
hidden inside the class implementation instead of being strewn
everywhere.  First impression, start with changing every mPoS
.x, .y direct access to a function on the object (no, not setX(),
getX(), nonsense, but move(d,a)).  To see what it takes to do 
that, just try making x and y and mPos private and give a go at

To do the least little thing, you have to get rid of the legacy
first.  It is obvious from the code.  So, my question, under
the current "managmement", why has this not happenned?  For so
many years.  My only conclusion is that the current "management"
is incapable of doing it for one reason or another.


On Tue, 22 Nov 2011, Lorenzo Marcantonio wrote:

> On Tue, Nov 22, 2011 at 06:39:25AM -0700, Brian F. G. Bidulock wrote:
> > I was working with 5 and 7mil LVDS and CMI pairs and low and
> > behold, someone put integer trig functions in kicad instead of
> > using, oh, gee, the floating point processor.  Well, when the
> > internal unit is a 1/10 mil and you have a 5 mil line, the
> > trig functions have a round-off error at a 45-degree angle
> > and DRC fails at each bend of the differential pair.  Annoying?
> > DRC was rendered useless.  So what, I change them to 4.9 mil and
> > put on the fab drawing that all 4.9 mil lines are to be made 5
> > mil lines?  Don't think so.  This is but one example of about
> Sadly I can agree on these... just yesterday I submitted to fab
> a 4-layer board (*really* below the tech of your example, but there are
> high-speed usb lines, so controlled differential impedance routing);
> well to be sure I did the drc before submit with cam350 and there were
> lots of 0.1mils disagreement. I agree that at your signal rates *that*
> could give you signal integrity issues!
> I hope that one of the 'vetoed' changes wasn't the removal of the trig
> tables...
> -- 
> Lorenzo Marcantonio
> Logos Srl

Brian F. G. Bidulock    � The reasonable man adapts himself to the �
bidulock@xxxxxxxxxxx    � world; the unreasonable one persists in  �
http://www.openss7.org/ � trying  to adapt the  world  to himself. �
                        � Therefore  all  progress  depends on the �
                        � unreasonable man. -- George Bernard Shaw �

Follow ups