On Sat, 2011-07-23 at 19:38 -0700, Andrew Poelstra wrote: > Hey all, > > On a recent bug report, Peter C. asked for a summary of the > remaining work needed for the metric conversion. Here you go: > > > It has been a busy week for me so no progress in the last > eight days or so. Even so, it's been a long time since my > last update... > > On my personal branch I have made a fair bit of progress > that has not been pushed. I don't want to publish these > changes yet because I'm still reordering and revising them. > > Another reason not to push is that I have converted PCB.Grid > and Settings.Grid from double to Coord (an integer unit). This > causes -severe- rounding errors for people using metric grids > with cmil base units. > > Anyway, here are the commits I have made but not pushed: > > 1. Introduce Coord and Angle units, set a bunch of BDimension, > LocationType and int variables in global.h to one of these. > Convert pcb-printf to use these (including adding %ma spec > to print angles). Oops, I've just been playing with the grid snap code and no doubt introducing additional uses of "LocationType" which you will need to fix up. Any chance you could push this one ASAP, or does it cause regressions? > 2. Convert grid units to Coord. Set mm/mil autodetect code to > look for multiples of 127nm (see bug lp-811393), though I > doubt this will work properly with cmil base units. Unlikely I would imagine. > 3. Add scale-factor lookup functions to pcb-printf and make > GetValue use this instead of its own table. Now there is > only one table of units, in pcb-printf.c, and everything > should be using it. > > 4. Upgrade unit structures in pcb-printf. Now units have a > "real" suffix that pcb uses internally and in file.c, and > an internationalized copy of the same suffix. Is there any use-case for I18N suffixes? I would imagine units are pretty much universal and language agnostic - unless you are spelling them out, e.g. "mÃtre" (French) vs. "metre" (English) / "meter" (American). > In principle, just audits. The ones I have done so far have been quick > and easy, essentially just replacing LocationType/BDimension with Coord, > using Angle, using NormalizeAngle() and Distance() instead of repeating > code. Nothing deep. > > I may even have been done by now except that when auditing search.c, I > found the arc-intersection problems that lead to a recent long thread > on this board. When I get a free moment (probably not till tomorrow) I > will just post a bug report and move on, "fixing" the unit handling > without fixing the actual algorithm. Always *BLEEPING* arcs which cause grief. If you could describe a perfect circle with B-Splines, I would be up for killing the "arc" primitive and replacing it with something a little more robust (unique) in how it may be defined. > I expect that aside from that, everything left will be easy. I just need > to spend some time and git'er'done. > > After all the source has been audited, I can commit the small changes to > const.h that actually do the conversion. Then I'll push and you guys can > jump on me for all the bugs I've caused. I'm looking forward to opening my "mm" designs with a "mm" grid and not chasing lost of off-grid gremlins ;) Let me know if I can be of any help. Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user