On Thu, 2010-01-28 at 19:05 -0600, Mark Rages wrote:
On Thu, Jan 28, 2010 at 3:50 PM, DJ Delorie d...@delorie.com wrote:
I was afraid of that...
:-)
So I guess I need to change the Arc object to store the angles in
floating-point and bump the file format version.
Any objections?
On Fri, Jan 29, 2010 at 6:28 AM, Peter Clifton pc...@cam.ac.uk wrote:
On Thu, 2010-01-28 at 19:05 -0600, Mark Rages wrote:
On Thu, Jan 28, 2010 at 3:50 PM, DJ Delorie d...@delorie.com wrote:
I was afraid of that...
:-)
So I guess I need to change the Arc object to store the angles in
I have two boards with gerber files. (Not drawn with PCB). A PCB
manufacturer told me they will give me a deal on a panel if I do the
step and repeat myself.
It is a $750 savings so it is worth a few hours of work.
I thought gerbv would do it, but it only views data. Is there a tool
that will
On Wed, 2010-01-27 at 14:05 +, Peter Clifton wrote:
but this has changed the output font size. The change has broken of
my schematics and symbols (my issue, not gEDA's - that's what happens
when you work with a dev version). I prefer the old scaling, and would
like to know what I need
On Fri, 2010-01-29 at 09:00 -0600, Mark Rages wrote:
Assuming: largest arc is 24 inches, and the desired precision 1e-5 inches.
A gentle very gentle curve would require more, but certainly the above
would be large enough for most of the applications I've seen for PCBs
which have rotational
On Fri, 2010-01-29 at 09:57 -0600, Kipton Moravec wrote:
I have two boards with gerber files. (Not drawn with PCB). A PCB
manufacturer told me they will give me a deal on a panel if I do the
step and repeat myself.
It is a $750 savings so it is worth a few hours of work.
I thought gerbv
double-precision floating-point would maintain more than sufficient
accuracy over the (0,360] range.
Try to avoid floating point for storage.
Arcs use sines and cosines to calculate endpoints, so any losses in
storing the angle a 64-bit double are irrelevent, and integer angles
are stores
On Fri, Jan 29, 2010 at 10:50 AM, Peter Clifton pc...@cam.ac.uk wrote:
On Fri, 2010-01-29 at 09:00 -0600, Mark Rages wrote:
Assuming: largest arc is 24 inches, and the desired precision 1e-5 inches.
A gentle very gentle curve would require more, but certainly the above
would be large enough
On Fri, 2010-01-29 at 11:09 -0600, Mark Rages wrote:
Seriously, why? all programming languages from C on up have
facilities to parse and write floating point. And it makes the file
more human-readable, because you don't have to do mental arithmetic to
understand a measurement.
When did I
30.12123
Cropping up in files un-necessarily.
Last time we discussed this, we talked about the sig fig problem. I
don't recall the results, but yeah, we need some rules about rounding
and such.
___
geda-user mailing list
On Jan 29, 2010, at 10:01 AM, DJ Delorie wrote:
We can store angles in double precision
with a precision of 1E-10 which is *far* more than we need.
Considering we're talking about mechanical systems, you're deep in
the world of ultra stable systems and ultra precision metrology if
you're
single-precision is 24 bits mantissa, we need nine for 0..360, leaving
four digits after the decimal point. That's 1 mil chord per 600 inch
radius, approximately. Still plenty.
___
geda-user mailing list
geda-user@moria.seul.org
On Fri, 2010-01-29 at 13:03 -0500, DJ Delorie wrote:
Well, here it is. Yes, I know it's not in git's pretty format, but
it's a bunch of local commits that make no sense separately. Discuss,
then I'll commit it all.
I'm interested in the diffstat (re-ordered to show the biggest changes):
Minor nit - pcblf is not a great name for the backend. Outside our
circle, lf is probably not something many will understand, and might
end up being one of those FAQ's like Ben mode.
Yup. Suggestions? pcbfa? pcbfwd? pcbimport? pcbmigrate? sch2pcb?
Netlist(Add,name,pin,defer)
On Fri, 2010-01-29 at 14:04 -0500, DJ Delorie wrote:
Good idea. Should freeze/thaw nest, or be a simple flag?
Many implementations nest, emitting the notify when the count gets to
zero. I don't imagine it would be too hard to make the implementation
nest though. I can't (at the moment), think
On Fri, 29 Jan 2010 14:04:29 -0500
DJ Delorie d...@delorie.com wrote:
Minor nit - pcblf is not a great name for the backend. Outside our
circle, lf is probably not something many will understand, and might
end up being one of those FAQ's like Ben mode.
Yup. Suggestions? pcbfa?
On Fri, 2010-01-29 at 14:02 -0600, Vanessa Ezekowitz wrote:
On Fri, 29 Jan 2010 14:04:29 -0500
DJ Delorie d...@delorie.com wrote:
Minor nit - pcblf is not a great name for the backend. Outside our
circle, lf is probably not something many will understand, and might
end up being one
On Fri, 2010-01-29 at 13:03 -0500, DJ Delorie wrote:
import::src0 ... import::src99 (etc)
schematic files. Note that the list stops at the first
missing number in sequence, even if there are higher numbered
sources present.
Since the import method is gnetlist, I assume we
A couple of options I thought of pcb-action or pcb-actions. (Since
it effectively creates a PCB action script - is that right?)
Right, but there are more types of action scripts than just the one
this produces.
(Although since it is gEDA specific, it might be good to mention that)
It isn't.
Since the import method is gnetlist, I assume we don't have to make
this a gEDA specific field. I did think (briefly) that we ought to
name-space the sources for Import schematics.
What's geda-specific about import::src4 ?
For sake of argument, if we had a xcircuit import method, I could
Is there any way to get better resolution? One degree is 25 mils at
my radius.
Sure, draw yourself a nice short straight segment. If your arc is extra
ordinarily thick, draw a trapezoidal polygon instead.
The point here is that even a 1 degree arc at your radius is
21 matches
Mail list logo
