>I don't think the copper shape / masking / clearance of the via is
>necessarily primitive. Granted, in 99.9% of cases it can be described by
>circular copper geometry on each connected layer, but support for
>arbitrary pad-stacks for components might as well extend to arbitrary
>via geometry.
>I'
On Sep 6, 2010, at 6:20 PM, Peter Clifton wrote:
> I'm pretty sure most holes in PCBs are round, but then some connectors
> have rectangular cut-outs (probably routed), but possibly stamped /
> reamed out.
You don't do focal planes, I guess. Routed-out rectangle-like (rounded corners,
of course
On 09/05/2010 10:21 AM, Bert Timmerman wrote:
On 09/04/2010 10:19 PM, Andrew Poelstra wrote:
I have one more suggestion: the facility to create recursive PCBs.
Recursive PCBs could work the same way as the footprint
re-use: a node could contain a reference to a parent node;
the parent node co
On Sep 6, 2010, at 5:49 PM, Bob Paddock wrote:
> Several times now in this thread I keep thinking that the language
> Forth is being described. 'Words' built up on previously defined
> 'words'...
It goes back to Euclid. "Theorems" built up on previously proven "theorems",
with a small se
> I think (hope) DJ was being sarcastic
I was.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Tue, 2010-09-07 at 10:38 +0200, Kovacs Levente wrote:
> On Mon, 6 Sep 2010 16:32:10 -0400
> DJ Delorie wrote:
>
> > Arcs can be simulated with many short lines, so the only primitive we
> > need are lines. Of course, if "line" is a two-point polygon, then the
> > only primitive we need is pol
On Sep 6, 2010, at 8:31 PM, Rick Collins wrote:
> I have often thought that I would prefer to write an HDL that works like
> Forth.
I believe Chuck Moore (the inventor of Forth) beat you to it.
http://www.colorforth.com/vlsi.html
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.c
On Mon, 6 Sep 2010 16:32:10 -0400
DJ Delorie wrote:
> Arcs can be simulated with many short lines, so the only primitive we
> need are lines. Of course, if "line" is a two-point polygon, then the
> only primitive we need is polygons.
So, your pcb file would contain nothing but polygons. This wo
Rick -
On Mon, Sep 06, 2010 at 10:31:15PM -0400, Rick Collins wrote:
>> Several times now in this thread I keep thinking that the language Forth is
>> being described. 'Words' built up on previously defined 'words'...
> I have often thought that I would prefer to write an HDL that works like
> F
At 07:49 PM 9/6/2010, you wrote:
> I like the idea of using geometric shapes at the lowest level, but for
> most PCBs this is *way* too low-level to be efficient. We need some
> way of arbitrarily grouping shapes, grouping groups, etc, and creating
> some sort of macro/library/callout for those
On Mon, Sep 06, 2010 at 10:27:25PM +0200, Levente Kovacs wrote:
>
> I prefer
>
> line,
> polygon,
> circle,
> arc.
>
> Why arc and circle are not merged? Because the diameter of the arc is the
> center of the bent line; however, the diameter of a circle is the edge.
>
I don't understand
On Mon, 2010-09-06 at 10:05 -0700, Andrew Poelstra wrote:
> > > via
> >
> > Definitely not primitive. A hole in one or more layers with conductive
> > material in it.
> >
>
> Again, while geometrically a via is not primitive, I think that in PCB
> terms, a via is primitive. It can exist on sev
I like the idea of using geometric shapes at the lowest level, but
for
most PCBs this is *way* too low-level to be efficient. We need some
way of arbitrarily grouping shapes, grouping groups, etc, and
creating
some sort of macro/library/callout for those groups, so th
On Mon, Sep 6, 2010 at 10:47 AM, John Doty <[1]...@noqsi.com> wrote:
On Sep 5, 2010, at 12:55 PM, Andrew Poelstra wrote:
> It's because it's inflexible and unintuitive.
The gEDA schematic format is flexible, intuitive, easy to parse,
easy to generate, and well described by conc
On 09/06/2010 04:32 PM, DJ Delorie wrote:
Or, could we base everything off of lines, attach a 'curvature'
property to create arcs, and build polygons from that.
Arcs can be simulated with many short lines, so the only primitive we
need are lines. Of course, if "line" is a two-point polygon, the
On 09/06/2010 04:54 PM, DJ Delorie wrote:
Yes. Build higher-level objects by composition, not merely by
listing.
I was arguing for the opposite - separate the compositing from the
grouping, so that when you *do* group, you mostly just list.
Even internally to PCB, I'd want to keep "ex
On 09/06/2010 04:27 PM, Levente Kovacs wrote:
On Mon, 6 Sep 2010 12:57:59 -0700
Andrew Poelstra wrote:
Or, could we base everything off of lines, attach a 'curvature'
property to create arcs, and build polygons from that.
I woldn't do that. The file would end up consisting of the sa
On Mon, Sep 06, 2010 at 04:49:32PM -0400, DJ Delorie wrote:
>
> > Why have any distinction between "footprint" and other fragments of
> > layout (like hierarchical blocks)?
>
> Because PCB needs to deal with boards at the semantic level, not just
> the physical level. Padstacks have to "exist" a
On Sep 6, 2010, at 2:54 PM, DJ Delorie wrote:
>
>> Yes. Build higher-level objects by composition, not merely by
>> listing.
>
> I was arguing for the opposite - separate the compositing from the
> grouping, so that when you *do* group, you mostly just list.
>
> Even internally to PCB, I'd wan
On Sep 6, 2010, at 2:49 PM, DJ Delorie wrote:
>
>> Why have any distinction between "footprint" and other fragments of
>> layout (like hierarchical blocks)?
>
> Because PCB needs to deal with boards at the semantic level, not just
> the physical level.
Yes. As gschem has to deal with schematic
> Yes. Build higher-level objects by composition, not merely by
> listing.
I was arguing for the opposite - separate the compositing from the
grouping, so that when you *do* group, you mostly just list.
Even internally to PCB, I'd want to keep "exemplar" composites as a
library called by referen
On Mon, Sep 06, 2010 at 04:40:47PM -0400, DJ Delorie wrote:
>
> I like the idea of using geometric shapes at the lowest level, but for
> most PCBs this is *way* too low-level to be efficient. We need some
> way of arbitrarily grouping shapes, grouping groups, etc, and creating
> some sort of macr
> Why have any distinction between "footprint" and other fragments of
> layout (like hierarchical blocks)?
Because PCB needs to deal with boards at the semantic level, not just
the physical level. Padstacks have to "exist" at the element level so
they can be tied to the netlist, for example. A
On Sep 6, 2010, at 2:40 PM, DJ Delorie wrote:
>
>> Why arc and circle are not merged? Because the diameter of the arc
>> is the center of the bent line; however, the diameter of a circle is
>> the edge.
>
> I.e. you're listing a *stroked* arc vs a *filled* circle?
>
> I like the idea of using
On Sep 6, 2010, at 2:27 PM, Levente Kovacs wrote:
> And of course we have to implement padstacks at the footprint level.
Why have any distinction between "footprint" and other fragments of layout
(like hierarchical blocks)?
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j..
> Why arc and circle are not merged? Because the diameter of the arc
> is the center of the bent line; however, the diameter of a circle is
> the edge.
I.e. you're listing a *stroked* arc vs a *filled* circle?
I like the idea of using geometric shapes at the lowest level, but for
most PCBs this
> Or, could we base everything off of lines, attach a 'curvature'
> property to create arcs, and build polygons from that.
Arcs can be simulated with many short lines, so the only primitive we
need are lines. Of course, if "line" is a two-point polygon, then the
only primitive we need is polygon
On Mon, 6 Sep 2010 12:57:59 -0700
Andrew Poelstra wrote:
> Or, could we base everything off of lines, attach a 'curvature'
> property to create arcs, and build polygons from that.
I woldn't do that. The file would end up consisting of the same stuff. It's
like you could only have points.
I thin
On Mon, Sep 06, 2010 at 12:16:21PM -0600, John Doty wrote:
>
> On Sep 6, 2010, at 11:54 AM, Andrew Poelstra wrote:
>
> > But I'm worried that by dropping down to basically a vector
> > drawing, we're going too far.
>
> The difference isn't so much in the primitives, but the machinery of
> compos
John Doty wrote:
> The gEDA schematic format is flexible, intuitive, easy to parse,
> easy to generate, and well described by concise documentation.
Not true, on all accounts.
It relies on positional parameters. Nuff said.
---<)kaimartin(>---
--
Kai-Martin Knaak
On Sep 6, 2010, at 11:54 AM, Andrew Poelstra wrote:
> But I'm worried that by dropping down to basically a vector
> drawing, we're going too far.
The difference isn't so much in the primitives, but the machinery of
composition of those into higher level things. Consider gschem. At the GUI
leve
On 09/06/2010 11:59 AM, Kovacs Levente wrote:
I'd add a capability of storing net information along with lines, polygons,
vias, and other copper objects. It would then make it unnecessary to have the
"new lines arcs clear polygons" stuff. A line in a polygon with the same
net wouldn't clear.
Lev
On Sep 6, 2010, at 10:54 AM, Andrew Poelstra wrote:
>>
> Sounds good. But I'm worried that by dropping down to basically a vector
> drawing, we're going too far. However, given that any decent file format
> will let us create PCB objects from geometric shapes, perhaps this is
> an unjustified fea
On Mon, Sep 06, 2010 at 11:24:58AM -0600, John Doty wrote:
>
> Choosing the right level for the primitives is important. I wouldn't drop
> below a "planar stack of geometric shapes" here. But I wouldn't go higher
> for primitives either. One might very well wish to draw arbitrary shapes
> in silk,
On Sep 6, 2010, at 11:05 AM, Andrew Poelstra wrote:
> On Mon, Sep 06, 2010 at 10:43:50AM -0600, John Doty wrote:
>>
>> On Sep 6, 2010, at 10:33 AM, Andrew Poelstra wrote:
>>
>>> On Mon, Sep 06, 2010 at 09:53:36AM -0600, John Doty wrote:
Need some geometric shapes. Need to be able to
On Mon, Sep 06, 2010 at 10:43:50AM -0600, John Doty wrote:
>
> On Sep 6, 2010, at 10:33 AM, Andrew Poelstra wrote:
>
> > On Mon, Sep 06, 2010 at 09:53:36AM -0600, John Doty wrote:
> >>
> >> Need some geometric shapes. Need to be able to attach material properties
> >> to them (including "vacuum"
On Sep 6, 2010, at 10:33 AM, Andrew Poelstra wrote:
> On Mon, Sep 06, 2010 at 09:53:36AM -0600, John Doty wrote:
>>
>> Need some geometric shapes. Need to be able to attach material properties
>> to them (including "vacuum" for holes).
>>
>
> How about?:
> trace (inc. arcs, pads)
Trace?
On Mon, Sep 06, 2010 at 09:53:36AM -0600, John Doty wrote:
>
> Need some geometric shapes. Need to be able to attach material properties
> to them (including "vacuum" for holes).
>
How about?:
trace (inc. arcs, pads)
polygon(inc. rectangle, etc)
circle (inc. quarter-circle, hal
On 9/6/10 10:56 AM, timecop wrote:
So gschem and gnetlist must obviously be constantly failing, suffer from
horrible inflexibility, and users must live in a fog of file format driven
error. Except they don't.
The REAL problem with opensource and contributors like you, is that
they're complet
On Sep 6, 2010, at 9:48 AM, Stephan Boettcher wrote:
> John Doty writes:
>
>> On Sep 5, 2010, at 10:43 AM, Stephan Boettcher wrote:
>>
>>> Yes, the gschem file format is much less accessible for
>>> hand/awk/sed-editing than the pcb file format.
>>
>> Huh? gschem format is *trivial* to pars
On Sep 6, 2010, at 10:00 AM, Kovacs Levente wrote:
> Pick and place points?
Not primitive. Composed of a geometric object tagged to identify it as a pick
and place point. We should, of course, allow arbitrary attributes to be
attached to any object to allow for things like this (and much more)
On Sep 6, 2010, at 9:59 AM, Kovacs Levente wrote:
>
> I'd add a capability of storing net information along with lines, polygons,
> vias, and other copper objects. It would then make it unnecessary to have the
> "new lines arcs clear polygons" stuff. A line in a polygon with the same
> net would
On Sat, 4 Sep 2010 22:10:17 -0700
Steven Michalske
wrote:
> Any other thoughts?
Pick and place points?
--
Kovacs Levente
Voice: +36705071002
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-us
I'd add a capability of storing net information along with lines, polygons,
vias, and other copper objects. It would then make it unnecessary to have the
"new lines arcs clear polygons" stuff. A line in a polygon with the same
net wouldn't clear.
Levente
--
Kovacs Levente
Voice: +36705071002
On Sep 6, 2010, at 9:46 AM, Andrew Poelstra wrote:
> On Mon, Sep 06, 2010 at 09:32:44AM -0600, John Doty wrote:
>>
>> But maybe, in the discussion of file formats, we can come up with a
>> way to describe a printed circuit board in a clean, well-factored way.
>>
>
> Well, what primitives would
On Mon, Sep 06, 2010 at 08:46:03AM -0700, Andrew Poelstra wrote:
>
> Well, what primitives would we need? The ones I can think of are
> trace, polygon, net and drc class.
>
Oh, and via.
>
> Andrew
>
___
geda-user mailing list
geda-user@moria.seul
John Doty writes:
> On Sep 5, 2010, at 10:43 AM, Stephan Boettcher wrote:
>
>> Yes, the gschem file format is much less accessible for
>> hand/awk/sed-editing than the pcb file format.
>
> Huh? gschem format is *trivial* to parse in awk. Use rules like:
>
> $1==L {
> x1 = $2
> y1 =
On Mon, Sep 06, 2010 at 09:32:44AM -0600, John Doty wrote:
>
> But maybe, in the discussion of file formats, we can come up with a
> way to describe a printed circuit board in a clean, well-factored way.
>
Well, what primitives would we need? The ones I can think of are
trace, polygon, net and dr
On Sep 6, 2010, at 8:22 AM, Ethan Swint wrote:
> Woah... I intended this thread for *what* we want to put in the file format
> to allow one to easily assign relationships between and characteristics of
> elements.
The reason you can't is that pcb and its file format aren't well factored. You
On Sep 5, 2010, at 10:43 AM, Stephan Boettcher wrote:
> Yes, the gschem file format is much less accessible for
> hand/awk/sed-editing than the pcb file format.
Huh? gschem format is *trivial* to parse in awk. Use rules like:
$1==L {
x1 = $2
y1 = $3
...
Or for simple
On Sep 6, 2010, at 8:56 AM, timecop wrote:
>> So gschem and gnetlist must obviously be constantly failing, suffer from
>> horrible inflexibility, and users must live in a fog of file format driven
>> error. Except they don't.
>
>
> The REAL problem with opensource and contributors like you, i
> So gschem and gnetlist must obviously be constantly failing, suffer from
> horrible inflexibility, and users must live in a fog of file format driven
> error. Except they don't.
The REAL problem with opensource and contributors like you, is that
they're completely incapable of accepting any [
On Sep 5, 2010, at 7:10 PM, DJ Delorie wrote:
>
>>> We are NOT going with another position-determines-meaning file format.
>>
>> Why?
>
> Consider the parser for the PIN object:
>
> Pin [rX rY Thickness Clearance Mask Drill "Name" "Number" SFlags]
> Pin (rX rY Thickness Clearance Mask Drill "
On Sep 5, 2010, at 1:56 PM, kai-martin knaak wrote:
> Stefan Salewski wrote:
>
>> One disadvantage of that format may be:
>> We have lines starting with a letter followed by up to 16 decimal
>> numbers -- hand editing such lines may be difficult. Not a problem for
>> me, I do not intend hand edi
On Sep 5, 2010, at 12:55 PM, Andrew Poelstra wrote:
> It's because it's inflexible and unintuitive.
The gEDA schematic format is flexible, intuitive, easy to parse, easy to
generate, and well described by concise documentation.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
First grow up, you are the one crying
And here is the solution for making the version control with git understand a
zipped pcb file.
http://the-gay-bar.com/2010/06/23/managing-zip-based-file-formats-in-git/
In summary you tell git that to diff the file it needs to me unzipped first.
Ste
On Sep 5, 2010, at 6:29 PM, timecop wrote:
> On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra wrote:
>> On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote:
>>>
But when each parameter in the file has a name, than file size may
become really large, e.g. for files generated with
On Mon, Sep 6, 2010 at 10:27 AM, Andrew Poelstra wrote:
> On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote:
>>
>> > But when each parameter in the file has a name, than file size may
>> > become really large, e.g. for files generated with the topological
>> > router, with lot of arcs.
>>
On Sun, Sep 05, 2010 at 09:18:01PM -0400, DJ Delorie wrote:
>
> > But when each parameter in the file has a name, than file size may
> > become really large, e.g. for files generated with the topological
> > router, with lot of arcs.
>
> Compression. Either gzip the text file, or use an alternat
> But when each parameter in the file has a name, than file size may
> become really large, e.g. for files generated with the topological
> router, with lot of arcs.
Compression. Either gzip the text file, or use an alternate binary
file (smaller *and* faster).
> > We are NOT going with another position-determines-meaning file format.
>
> Why?
Consider the parser for the PIN object:
Pin [rX rY Thickness Clearance Mask Drill "Name" "Number" SFlags]
Pin (rX rY Thickness Clearance Mask Drill "Name" "Number" NFlags)
Pin (aX aY Thickness Drill "Name" "Numbe
On Sun, Sep 05, 2010 at 10:01:47PM +0200, Stefan Salewski wrote:
>
> But when each parameter in the file has a name, than file size may
> become really large, e.g. for files generated with the topological
> router, with lot of arcs.
>
If every parameter had a name like 'x', 'y', 'w', 'h', 'r', it
On Sun, 2010-09-05 at 21:56 +0200, kai-martin knaak wrote:
> Stefan Salewski wrote:
>
> > One disadvantage of that format may be:
> > We have lines starting with a letter followed by up to 16 decimal
> > numbers -- hand editing such lines may be difficult. Not a problem for
> > me, I do not intend
Stefan Salewski wrote:
> One disadvantage of that format may be:
> We have lines starting with a letter followed by up to 16 decimal
> numbers -- hand editing such lines may be difficult. Not a problem for
> me, I do not intend hand editing.
More precisely: Positional parameters are bad.
Mapping
On Sun, Sep 05, 2010 at 07:22:14PM +0200, Stefan Salewski wrote:
> On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote:
> > > We have lines starting with a letter followed by up to 16 decimal
> > > numbers
> >
> > We are NOT going with another position-determines-meaning file format.
> >
> >
>
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote:
> > We have lines starting with a letter followed by up to 16 decimal
> > numbers
>
> We are NOT going with another position-determines-meaning file format.
>
>
Why?
Is manually editing the only reason?
I guess data in most files on our comp
On Sun, 2010-09-05 at 12:48 -0400, DJ Delorie wrote:
> > We have lines starting with a letter followed by up to 16 decimal
> > numbers
>
> We are NOT going with another position-determines-meaning file format.
May I suggest that while deciding on a file format and choosing how it
will work it wou
> We have lines starting with a letter followed by up to 16 decimal
> numbers
We are NOT going with another position-determines-meaning file format.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-
Stefan Salewski writes:
> On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote:
>> All of this discussion of formats misses the shining example that's
>> already in gEDA: the schematic format.
>
> Yes. Recently I begun studying that format and started writing a parser
> in Ruby -- really easy.
>
>
On Sun, Sep 05, 2010 at 05:47:12PM +0200, Stefan Salewski wrote:
>
> One disadvantage of that format may be:
> We have lines starting with a letter followed by up to 16 decimal
> numbers -- hand editing such lines may be difficult. Not a problem for
> me, I do not intend hand editing.
>
Sounds li
On Sun, 2010-09-05 at 09:30 -0600, John Doty wrote:
> All of this discussion of formats misses the shining example that's
> already in gEDA: the schematic format.
Yes. Recently I begun studying that format and started writing a parser
in Ruby -- really easy.
One disadvantage of that format may be
All of this discussion of formats misses the shining example that's already in
gEDA: the schematic format. Now *there's* a work of genius.
1. The format is based on a small, well-chosen set of elementary objects.
2. Elementary objects are represented by one-line tagged records of fixed
format (
Hi,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Ethan Swint
> Sent: Sunday, September 05, 2010 4:06 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: PCB format wishlist
>
> On 09/
On 09/04/2010 10:19 PM, Andrew Poelstra wrote:
I have one more suggestion: the facility to create recursive PCBs.
What this will look like in the file format, I dunno. But we should
keep it in mind.
Recursive PCBs could work the same way as the footprint re-use: a node
could contain a refere
On 09/04/2010 10:04 PM, Andrew Poelstra wrote:
3) Connectivity information: include the connection information
between line segments, similar to (but not necessarily exactly!) SVG
format, where multiple points and arcs can be included in one line.
I'm not sure what you're getting at here.
On Sep 4, 2010, at 4:50 PM, Ethan Swint wrote:
> In parallel to how we want to implement the PCB file format, why don't we
> have a separate thread on *what* we want to implement? I'll propose the
> following as a starting point:
>
> 1) Better angle support: include rotation (in degrees, rota
On Sat, Sep 04, 2010 at 07:50:51PM -0400, Ethan Swint wrote:
> In parallel to how we want to implement the PCB file format, why
> don't we have a separate thread on *what* we want to implement?
> I'll propose the following as a starting point:
>
I have one more suggestion: the facility to create r
On Sat, Sep 04, 2010 at 07:50:51PM -0400, Ethan Swint wrote:
> In parallel to how we want to implement the PCB file format, why
> don't we have a separate thread on *what* we want to implement?
> I'll propose the following as a starting point:
>
> 1) Better angle support: include rotation (in degr
78 matches
Mail list logo
