On 9/6/10, Peter Clifton wrote:
...
> confusing "non-copper" with "skip-drc" is
> probably a bad idea.
...
Thank you, your suggestion is really reasonable.
I renamed the attribute to PCB::non-copper
and corrected the variable name and comments accordingly;
probably it does not make the patch per
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 Tue, Sep 7, 2010 at 1:36 AM, Kai-Martin Knaak
wrote:
> Atommann wrote:
>
>> 1. The Toporouter really works and it's very cool.
>
> Last time I checked, it wasn't possible to let the topo router do only
> selected rats. Did this change?
It has always been able to do only selected rats.
You are
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
> How about this: Let footprints contain a file name of an macro image
> from the top. Then, the photo mode could use the image to render a
> populated board. ;-)
I thought of that, but you need to be able to correctly align the
photo with the rotated/positioned element footprint.
> BTW, shadow
On 09/06/2010 06:51 PM, DJ Delorie wrote:
I needed an official photo of a board for a presentation, but the
boards aren't back from assembly yet. So I used a photo-mode export
of the PCB, and a photograph of a home-etched prototype, and 1-2 hours
of GIMP work...
http://www.delorie.com/pcb/tmp/
DJ Delorie wrote:
>
> I needed an official photo of a board for a presentation, but the
> boards aren't back from assembly yet. So I used a photo-mode export
> of the PCB, and a photograph of a home-etched prototype, and 1-2 hours
> of GIMP work...
>
> http://www.delorie.com/pcb/tmp/photo-mode-
I needed an official photo of a board for a presentation, but the
boards aren't back from assembly yet. So I used a photo-mode export
of the PCB, and a photograph of a home-etched prototype, and 1-2 hours
of GIMP work...
http://www.delorie.com/pcb/tmp/photo-mode-plus-plus.html
(yes, it's part o
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
On Sat, 2010-09-04 at 19:57 -0700, Steven Michalske wrote:
>
> Think BIG designs, a bloated file format will hurt. And I want PCB
> on my iPad. It has OpenGL ES, that would be putting it on a
> phone
Sounds like a fun project for the PCB+GL branch when I get some more
coding time ;) A fr
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
Brilliant!
That works
Thanks,
Oliver
__
From: John Doty
To: gEDA user mailing list
Sent: Mon, September 6, 2010 2:09:26 PM
Subject: Re: gEDA-user: gnetlist quitting after execl call
On Sep 6, 2010, at
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:49 PM, Oliver King-Smith wrote:
> John,
> Ah much improved. I tried using system* but now I don't seem to be
> getting my command line arguments. For example both
> (system* "/sw/share/gEDA/scheme/subfunction" (string-append " --m="
>
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
John,
Ah much improved. I tried using system* but now I don't seem to be
getting my command line arguments. For example both
(system* "/sw/share/gEDA/scheme/subfunction" (string-append " --m="
(number->string m) " --w="
(number->string w)
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 Mon, 2010-09-06 at 15:32 +0200, Kai-Martin Knaak wrote:
> Peter Clifton wrote:
>
> >> Why don't we just push this patch to HEAD? This works just great.
> >
> > One minor nit..
> >
> That is, the patch is rejected because of this minor nit?
I don't accept / reject patches per-se.. I was just
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
On Mon, 2010-09-06 at 09:30 +0200, Kovacs Levente wrote:
> On Sun, 05 Sep 2010 22:19:08 +0100
> Peter Clifton wrote:
>
> > I'd keep the "non-copper" / "skip-drc" ideas separate. We might (at
> > some point) have DRC rules for non-copper layers (not that I can
> > think of them at the moment, perh
> 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 1:08 PM, Oliver King-Smith wrote:
> I am extending gnetlist and I dislike scheme. To work around this I
> wrote a little program in C++ to do the heavy lifting and I am trying
> to call it from my scheme extension to gnetlist.
> I wrote the following function in scheme
I am extending gnetlist and I dislike scheme. To work around this I
wrote a little program in C++ to do the heavy lifting and I am trying
to call it from my scheme extension to gnetlist.
I wrote the following function in scheme:
(define magic:write_nmos_fet
(lambda (w l m)
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
Peter Clifton wrote:
> What command-line / printing script are you using?
I misread this as one of my favorite feature requests:
"command line printing"
How hard would it be to implement this?
---<)kaiamrtin(>---
--
Kai-Martin Knaak tel: +49-511-762-28
Atommann wrote:
> 1. The Toporouter really works and it's very cool.
Last time I checked, it wasn't possible to let the topo router do only
selected rats. Did this change?
---<)kaimartin(>---
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst.
Peter Clifton wrote:
>> Why don't we just push this patch to HEAD? This works just great.
>
> One minor nit..
>
That is, the patch is rejected because of this minor nit?
---<)kaimartin(>---
--
Kai-Martin Knaak tel: +49-511-762-2895
Universität Hannover, Inst. f
On Sun, 05 Sep 2010 22:19:08 +0100
Peter Clifton wrote:
> I'd keep the "non-copper" / "skip-drc" ideas separate. We might (at
> some point) have DRC rules for non-copper layers (not that I can
> think of them at the moment, perhaps apart from silk layer(s)).
Component outline vs. keep-in compone
66 matches
Mail list logo
