DJ Delorie wrote:
Perhaps we store the internal data in a structure that can be
exported/imported in *any* structured format, and let those who really
want format XYZ to add the import/export logic for it?
+=3, just repeat my self twice ;-)
___
ge
Kai-Martin Knaak wrote:
Andrew Poelstra wrote:
The problem I have with JSON (and to some extent, Lisp) is that it is
not self-documenting. You can't open a JSON document and immediately
see what everything is and what it does; it just looks like gibberish
and brackets.
+1
Whatever f
Has anyone looked into what it would take to properly quote footprint
names, so that hyphens *can* be used in them without m4 issues? I
mean, we don't have to support *m4* footprints with hyphens, but at
least get past that to find newlib names?
___
g
Steven Michalske wrote:
>>> We had that: M4 footprints. I never liked those, I could not figure out
>>> how to use them.
>>
>> But I love them!
>>
> I love them too!
>
I don't ;-)
> I keep mine up to date, so I don't use a - (dash) in foot print names,
> its a price I am willing to pay.
It
Hi Rick,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins
> Sent: Friday, September 17, 2010 4:05 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Functional blocks and
On Sep 17, 2010, at 9:17 AM, Michael Sokolov wrote:
> Stephan Boettcher wrote:
>
>> We had that: M4 footprints. I never liked those, I could not figure out
>> how to use them.
>
> But I love them!
>
I love them too!
I keep mine up to date, so I don't use a - (dash) in foot print names, its
Stephan Boettcher wrote:
> We had that: M4 footprints. I never liked those, I could not figure out
> how to use them.
But I love them!
MS
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
I've actually given this some thought. On one
hand it seems like a footprint file "language"
might seem like a good idea. But there is a lot
to consider. What is the real advantage over the
scripts you currently use to generate a fixed
format footprint file? What is the advantage
over a f
k...@aspodata.se (Karl Hammar) writes:
> I would like the file format to be "programmable", at least at the
> footprint level.
We had that: M4 footprints. I never liked those, I could not figure out
how to use them. But if you drop the parameters, and make a
non-parameterized top-level file for
Phil Frost:
...
> XML and YAML are equally capable of being made unreadable. Either can be
> made more readable by defining a reasonable schema and selecting a
> clueful output library.
>
> Neither sed nor awk can process XML or YAML the right way in all cases
> without reimplementing a libyaml or
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote:
> On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> > XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
> > I think that using a Lisp (or Lispy-looking) format would be extensible,
> > easy to parse
Phil Frost writes:
> I would point out a valid YAML representation of the above is also:
>
> {pin: {pinNumber: 2, pinName: rst, x1: 1234, y1: 4321, x2: 2345, y2: 4321,
> layer: component}}
> Neither sed nor awk can process XML or YAML the right way in all cases
> without reimplementing a libyam
On Mon, Sep 13, 2010 at 04:25:49PM -0700, Steven Michalske wrote:
> pin:
> pinNumber: 2
> pinName: "rst"
> x1: 1234
> y1: 4321
> x2: 2345
> y2: 4321
> layer: component
>
> or
> 2"rst"<\pinName>1234<\x1>4321<\y1>2345<\x2>5432<\y2>component<\layer><\pin>
I would point out a valid YAML
On 09/13/2010 09:57 PM, Ouabache Designworks wrote:
pin:
pinNumber: 2
pinName: "rst"
x1: 1234
y1: 4321
x2: 2345
y2: 4321
layer: component
or
2"rst"<\pinName>1234<\x1>4321<\y1>2345<\x2>5432<\y2>component<\layer><\pin>
I call
Steven Michalske writes:
> Now we may want to write a parser, and emitter, but that is a good
> amount of work, to serialize a data structure in the code that could
> be output be a data serializer that just works.
The emitter shall conserve order and formatting (probably not) or at
least be det
I prefer:
# -*- makefile -*-
CSA-L%.sch: CSA-1.sch Makefile
sed 's,^\(refdes\|netname\)=,&L$*_,' $< > $@
CSA-N%.sch: CSA-2.sch Makefile
sed 's,^\(refdes\|netname\)=,&N$*_,' $< > $@
FSH-S%.sch: FSH-1.sch Makefile
sed 's,^\(refdes\|netname\)=,&S$*_,' $< > $@
Nice,
but I prefer
#! /usr/bin/python
import yaml
from pprint import pprint
pcb = yaml.load('''
---
pin:
pinNumber: 2
pinName: "rst"
x1: 1234
y1: 4321
x2: 2345
y2: 4321
layer: component
...
''')
# or from file
#pcb = yaml.load(open(sys.argv[1], 'rb'))
ppri
pin:
pinNumber: 2
pinName: "rst"
x1: 1234
y1: 4321
x2: 2345
y2: 4321
layer: component
or
2"rst"<\pinName>1234<\x1>4321<\y1>2345<\x2>5432<\y2>component<\layer><\pin>
I call the second large, bloat, and ugly.
--
On Mon, Sep 13, 2010 at 7:51 PM, Andrew Poelstra wrote:
> On Mon, Sep 13, 2010 at 07:35:29PM -0400, Windell H. Oskay wrote:
>>
>> > I say no to raw XML as making out own format, but would use SVG with
>> > extra info embedded.
>> >
>> > This way our drawings would work in all modern web browsers,
On Mon, Sep 13, 2010 at 07:35:29PM -0400, Windell H. Oskay wrote:
>
> > I say no to raw XML as making out own format, but would use SVG with
> > extra info embedded.
> >
> > This way our drawings would work in all modern web browsers, we get all of
> > the primitives we would ever want, including
On Sep 13, 2010, at 5:39 PM, DJ Delorie wrote:
>
>> Widely used, classic, useful tools then.
>
> XML is easily parsed with Perl. It's more widely used than awk or
> sed, and far more useful.
And far more of a conceptual mess. But regardless of personal preference, why
not embrace the whole a
> Widely used, classic, useful tools then.
XML is easily parsed with Perl. It's more widely used than awk or
sed, and far more useful.
"Classic" is not a point in your favor here.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.o
On Sep 13, 2010, at 5:25 PM, Steven Michalske wrote:
> Arguably grep and sed will have issues with both XML or YAML
AWK is perhaps more important, as one can often do serious processing of data
in line-oriented formats using very short programs.
John Doty Noqsi Aerospace, Ltd.
htt
> I call the second large, bloat, and ugly.
>
> 98 chars vs 134 or 36% bigger for a pin with these mythical formats.
You're making my point. 36% is way under the 900% that I budgeted to show
that it still isn't a big deal in terms of file size-- absolutely
negligible in determining how portable
On Sep 13, 2010, at 5:26 PM, Windell H. Oskay wrote:
>> You can't easily parse it with simple tools like awk or sed. That's a
>> fact.
>
> No, it's not a fact.
>
> It's actually just you expressing your opinion that awk and sed are simple
> tools.
Widely used, classic, useful tools then.
John
> You can't easily parse it with simple tools like awk or sed. That's a
> fact.
No, it's not a fact.
It's actually just you expressing your opinion that awk and sed are simple
tools.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.
On Sep 13, 2010, at 3:32 PM, Rick Collins wrote:
> At 04:34 PM 9/13/2010, you wrote:
>
>> > But that is exactly what others have been saying, they are concerned
>> > about the file size they think they would get from XML... "I want to
>> > run PCB on my iPad", etc.
>>
>> File size just means a
On Sep 13, 2010, at 4:32 PM, Rick Collins wrote:
> As Windell says, the arguments against XML seem to be based on some sort of
> bias rather than any real facts against it.
You can't easily parse it with simple tools like awk or sed. That's a fact.
John Doty Noqsi Aerospace, Ltd
At 04:34 PM 9/13/2010, you wrote:
> But that is exactly what others have been saying, they are concerned
> about the file size they think they would get from XML... "I want to
> run PCB on my iPad", etc.
File size just means a bigger file to generate/parse. Doesn't affect RAM
use significantly
On Mon, Sep 13, 2010 at 02:31:34PM -0400, Rick Collins wrote:
> At 01:44 PM 9/13/2010, you wrote:
> >On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
> >>
> >> Why? I'd much rather handwrite XML than YAML.
> >
> >Really? It's not the filesize of XML documents that is the concern; i
On Sep 13, 2010, at 2:22 PM, Stefan Salewski wrote:
> On Mon, 2010-09-13 at 16:34 -0400, Windell H. Oskay wrote:
>>> But that is exactly what others have been saying, they are concerned
>>> about the file size they think they would get from XML... "I want to
>>> run PCB on my iPad", etc.
>>
>> F
> Sorry, I was not able to follow the whole discussion, but I do not like
> your arguments too much. XML may be fine -- if it has big benefits, that
> may be much more important than size.
I don't care about XML one way or the other, I was pointing out that the
argument presented against it was sl
My concerns with XML have always been on the "talking to it from
inside pcb" side. File size is nothing compared to the complexity of
supporting it in the first place.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mai
> Will that mean every time something new is added to the core, each
> set of import/export logic will break? Or is that part of making
> changes to the core, to update all affected functions?
Either the core's data structure will be flexible enough, or there
could be an intermediate layer tha
On Mon, 2010-09-13 at 16:34 -0400, Windell H. Oskay wrote:
> > But that is exactly what others have been saying, they are concerned
> > about the file size they think they would get from XML... "I want to
> > run PCB on my iPad", etc.
>
> File size just means a bigger file to generate/parse.
And
Will that mean every time something new is added to the core, each
set of import/export logic will break? Or is that part of making
changes to the core, to update all affected functions?
Rick
At 04:29 PM 9/13/2010, you wrote:
Perhaps we store the internal data in a structure that can be
ex
> But that is exactly what others have been saying, they are concerned
> about the file size they think they would get from XML... "I want to
> run PCB on my iPad", etc.
File size just means a bigger file to generate/parse. Doesn't affect RAM
use significantly, which is the major limit for small
Perhaps we store the internal data in a structure that can be
exported/imported in *any* structured format, and let those who really
want format XYZ to add the import/export logic for it?
___
geda-user mailing list
geda-user@moria.seul.org
http://www.s
At 01:44 PM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
>
> Why? I'd much rather handwrite XML than YAML.
Really? It's not the filesize of XML documents that is the concern; it is the
/redundant/ filesize. Even for a single-character tag, you need to
At 01:43 PM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
>
> On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
>
> > On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> > XML is far too heavy, agreed, and it's signal-to-noise r
On Sep 13, 2010, at 10:46 AM, John Doty wrote:
> The gschem format is as expressive as HTML, but having the braces stand alone
> on separate lines makes the structure easier to parse with simple tools.
> Simple is good.
Your definition of simple is (as usual) very different from mine.
http:
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
>
> On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
>
> > On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> > XML is far too heavy, agreed, and it's signal-to-noise ratio is
> > abysmal.
>
> Why? I'd
On Sep 13, 2010, at 11:23 AM, Windell H. Oskay wrote:
> I'm not sure that I see a good reason for the hatred of XML.
As one sysadmin I know put it, it allows the data representation to be as ugly
as you can imagine.
> I've never found the size of Inkscape documents to be absurd, for example,
On Mon, Sep 13, 2010 at 10:23:43AM -0700, Windell H. Oskay wrote:
>
> On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
>
> > On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> >> XML is far too heavy, agreed, and it's signal-to-noise ratio is
> > abysmal.
> >
> >
On Sep 13, 2010, at 9:26 AM, Ouabache Designworks wrote:
> On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
>> XML is far too heavy, agreed, and it's signal-to-noise ratio is
> abysmal.
>
> True on both counts and you would never want to handcraft a xml
> document.
W
On Sep 13, 2010, at 10:14 AM, Rick Collins wrote:
> Yes, if you have the file format provide adequate context information for
> humans to read, then you are adding weight and the file becomes heavy. I
> find that I can actually lift many gigabytes very easily, but some others
> seem to have m
At 11:40 AM 9/13/2010, you wrote:
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote:
> On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> > XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
> > I think that using a Lisp (or Lispy-looking) format wo
On Mon, Sep 13, 2010 at 11:57:11AM -0400, Ethan Swint wrote:
>
> Every time I run against it, I'm still in disbelief that, in this
> era, some of our most powerful and useful tools are restricted to
> one character for parsing, and that one character is furthermore
> restricted to newline!
>
Two
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> XML is far too heavy, agreed, and it's signal-to-noise ratio is
abysmal.
True on both counts and you would never want to handcraft a xml
document.
But thats not how your supposed to use it. You want to wri
On Mon, Sep 13, 2010 at 08:40:47AM -0700, Andrew Poelstra wrote:
> The problem I have with JSON (and to some extent, Lisp) is that it is
> not self-documenting. You can't open a JSON document and immediately
> see what everything is and what it does; it just looks like gibberish
> and brackets.
I
Andrew Poelstra wrote:
> The problem I have with JSON (and to some extent, Lisp) is that it is
> not self-documenting. You can't open a JSON document and immediately
> see what everything is and what it does; it just looks like gibberish
> and brackets.
+1
Whatever format is going to be chosen, i
XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
I think that using a Lisp (or Lispy-looking) format would be extensible,
easy to parse, and make the most people happy.
Allow me to toss out JSON. It is about as light weight as using S-EXP,
...else along those li
On Mon, Sep 13, 2010 at 11:26:28AM -0400, Joshua Boyd wrote:
> On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> > XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
> > I think that using a Lisp (or Lispy-looking) format would be extensible,
> > easy to parse
On Fri, Sep 03, 2010 at 09:08:25PM -0700, Andrew Poelstra wrote:
> XML is far too heavy, agreed, and it's signal-to-noise ratio is abysmal.
> I think that using a Lisp (or Lispy-looking) format would be extensible,
> easy to parse, and make the most people happy.
Allow me to toss out JSON. It is
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
On Sat, Sep 04, 2010 at 12:17:15PM -0400, DJ Delorie wrote:
>
> > But suppose the user creates a rule like, "all traces on Layer 3 must
> > be at least 5mm apart", and then saves the file and reloads it. Now the
> > information about what traces are affected is lost, except that all the
> > traces
On Sat, Sep 04, 2010 at 07:49:06PM -0700, Steven Michalske wrote:
>
> This is why I use yaml to store data. It was designed to be human
> readable. It holds most high level data structures. And is very
> low bloat. You can tag the yam code to say that this is a particular
> data structure, like
Hi Bob,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Bob Paddock
> Sent: Sunday, September 05, 2010 1:24 PM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Functional blocks and
IMHO, the "problem" with XML lies not in the bloat, even a factor
10 larger
would be acceptable, it's the <$TAGS> that have to be identical
across all
applications to have a "truly" exchangeable XML file.
[1]http://www.ibm.com/developerworks/xml/ XML can be easy or har
Behalf Of Bert Timmerman
> Sent: Sunday, September 05, 2010 11:13 AM
> To: 'gEDA user mailing list'
> Subject: Re: gEDA-user: Functional blocks and PCB format changes
>
> Hi Rick,
>
> > -Original Message-
> > From: geda-user-boun...@moria.seul.org
Hi Rick,
> -Original Message-
> From: geda-user-boun...@moria.seul.org
> [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins
> Sent: Sunday, September 05, 2010 12:38 AM
> To: gEDA user mailing list
> Subject: Re: gEDA-user: Functional blocks and
Yes,
I like walled gardens, you only let in those you trust. Don't like the walled
garden don't use it.
Anyhow, the software is free. Who cares about MY platform of choice be it
Linux, Mac OS X, or windows, all of which geda supports, and more.
On Sep 4, 2010, at 8:05 PM, timecop wrote:
On Sep 4, 2010, at 6:00 PM, kai-martin knaak wrote:
> Andrew Poelstra wrote:
>
>> The point is that we can't be sure what the future will bring in terms
>> of IOPS, storage capacity (even big servers often RAID together dozens
>> of small drives to get high speeds against low capacity).
>
iPAd is about as closedsores and proprietary as it gets; you sure you
want to support that?
On 5 Sep 2010 11:57, "Steven Michalske" <[1]smichal...@gmail.com>
wrote:
>
>
>
>
>
> On Sep 4, 2010, at 8:49 AM, Andrew Poelstra <[2]as...@sfu.ca> wrote:
>
>> On Sat, Sep
On Sep 4, 2010, at 8:49 AM, Andrew Poelstra wrote:
> On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote:
>>
>> Don't hold back, tell us how you really feel!
>>
>> The spec is large because it addresses a wide range of design
>> aspects, which is one of the great reasons for using
On Sep 3, 2010, at 9:45 PM, Andrew Poelstra wrote:
> On Fri, Sep 03, 2010 at 04:44:14PM -0700, Andrew Poelstra wrote:
>>
>> However, this also brings the ability to edit PCB components individually,
>> which means that some parts could have different layers than others, for
>> example
On Sep 3, 2010, at 9:11 PM, Andrew Poelstra wrote:
> On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote:
>> XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway?
>>
>
> For most data, XML ends up being > 50% tags (and < 50% data). It's hard to
> read for hum
On Sun, Sep 05, 2010 at 03:00:45AM +0200, kai-martin knaak wrote:
> Andrew Poelstra wrote:
>
> > The point is that we can't be sure what the future will bring in terms
> > of IOPS, storage capacity (even big servers often RAID together dozens
> > of small drives to get high speeds against low capa
Andrew Poelstra wrote:
> The point is that we can't be sure what the future will bring in terms
> of IOPS, storage capacity (even big servers often RAID together dozens
> of small drives to get high speeds against low capacity).
This kind of argument goes against any change. geda development
alr
How do you know PCB won't ever run on cell phones, or over a
slow network link
I have run gEDA and PCB over VNC, on slow links. Not fun.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda
On Sat, Sep 04, 2010 at 06:37:37PM -0400, Rick Collins wrote:
>
> So are you suggesting that we should, at this time, plan for running
> PCB on a cell phone? Do you want to design PCB to work on overtaxed
> virtual machines, if so, I expect there will be a lot more important
> things to optimize
I am currently having a conversation in the FreePCB forum about
DRC. I think copper only checking is not adequate. There are design
rules regarding solder mask which can not be checked properly just by
checking copper to copper rules.
Is there any checking done on the solder mask layer?
If
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 04.09.2010 01:44, schrieb Andrew Poelstra:
>
>
>
> Hey all,
>
>
> I am working on the structuring PCB files in terms of functional blocks,
> and generalizing/extending the DRC rule format. (Things have slowed down
> as summer is ending but I am
At 11:49 AM 9/4/2010, you wrote:
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote:
>
> Don't hold back, tell us how you really feel!
>
> The spec is large because it addresses a wide range of design
> aspects, which is one of the great reasons for using it, one file
> for the entire d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 04.09.2010 18:18, schrieb DJ Delorie:
>
>> How do you know PCB won't ever run on cell phones, or over a slow
>> network link, or on an embedded device or network PC or overtaxed
>> virtual machine?
>
> iPcb . . .
>
>
> __
>
> On Sep 4, 2010, at 4:30 AM, Ineiev wrote:
>
>> Hello, DJ;
>>
>> On 9/4/10, DJ Delorie wrote:
>>> Our DRC engine could use a complete rewrite. It doesn't get arcs
>>> right, for example.
>>
>> Could you elaborate on the arcs, please? what it doesn't do?
>
> I've been running into trouble
On Sep 4, 2010, at 4:30 AM, Ineiev wrote:
> Hello, DJ;
>
> On 9/4/10, DJ Delorie wrote:
>> Our DRC engine could use a complete rewrite. It doesn't get arcs
>> right, for example.
>
> Could you elaborate on the arcs, please? what it doesn't do?
I've been running into trouble with the DRC and
Andrew Poelstra wrote:
How do you know we won't one day
need to work with 1000-layer boards when suddenly it /does/
matter how heavy the file format is?
As in 3D circuitry in printed organic semiconductor...
printed along with volume-defining material for circuit and package in one...
We'll ma
Andrew Poelstra wrote:
suppose the user creates a rule like, "all traces on Layer 3 must
be at least 5mm apart", and then saves the file and reloads it. Now the
information about what traces are affected is lost, except that all the
traces on Layer 3 are coincedentally tagged with the rule.
What
> Hmm. How about two copper layers, which would by default map to the
> top and bottom layers (whatever they are) on the PCB that the footprint
> is being used in?
Stripline Antennas
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.
> How do you know PCB won't ever run on cell phones, or over a slow
> network link, or on an embedded device or network PC or overtaxed
> virtual machine?
iPcb . . .
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailm
> But suppose the user creates a rule like, "all traces on Layer 3 must
> be at least 5mm apart", and then saves the file and reloads it. Now the
> information about what traces are affected is lost, except that all the
> traces on Layer 3 are coincedentally tagged with the rule.
>
> What if the
I'll have to save a sample next time it happens, I can't reproduce it
manually :-P
Mostly it's when you're using the global puller or toporouter and it
makes all those sweeping graceful curves.
___
geda-user mailing list
geda-user@moria.seul.org
http:
On Sat, Sep 04, 2010 at 01:38:15AM -0400, DJ Delorie wrote:
>
> > 1. Refuse to export-as-footprints any PCB with more than one copper
> >layer. This will likely eliminate the most common problems.
>
> Edge connectors.
>
Hmm. How about two copper layers, which would by default map to the
top
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote:
>
> Don't hold back, tell us how you really feel!
>
> The spec is large because it addresses a wide range of design
> aspects, which is one of the great reasons for using it, one file
> for the entire design, schematic, layout, mechanic
On Sat, Sep 04, 2010 at 01:37:32AM -0400, DJ Delorie wrote:
>
> > If we tagged individual objects with rules it would be difficult to edit
> > rules in a systemetic way. So I don't think that's a good way to go.
>
> No, we tag objects with rule *names*. Hopefully rules can nest, so
> you can hav
Hello, DJ;
On 9/4/10, DJ Delorie wrote:
> Our DRC engine could use a complete rewrite. It doesn't get arcs
> right, for example.
Could you elaborate on the arcs, please? what it doesn't do?
Thanks,
Ineiev
___
geda-user mailing list
geda-user@moria.
Am 04.09.2010 05:29, schrieb Rick Collins:
> XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway?
>
> There is already a preliminary XML based CAD data spec proposed by IPC,
> you know, the guys who write specs for the PCB assembly industry...
>
> I don't know if it is the
On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote:
> But I suppose it is better to re-invent the wheel. There is no reason to
> try to foster any sort of compatibility in file formats between all the
> different CAD tools. There are always conversion programs to be written,
> no?
> The "heavy" issue is a red herring
The "heavy" issue impacts the difficulty in using XML as a toolkit.
> But I suppose it is better to re-invent the wheel. There is no
> reason to try to foster any sort of compatibility in file formats
> between all the different CAD tools.
That's a real r
> 1. Refuse to export-as-footprints any PCB with more than one copper
>layer. This will likely eliminate the most common problems.
Edge connectors.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/g
> If we tagged individual objects with rules it would be difficult to edit
> rules in a systemetic way. So I don't think that's a good way to go.
No, we tag objects with rule *names*. Hopefully rules can nest, so
you can have meta-rules like "signal-line-rule" or "12vac rule".
Without a tag, you
> What level of self proving would Andrew need to do to be eligible for
> Linux Fund payment?
LF work is a contract between LF and the developer. It's up to the
developer to prove themselves to LF, not to us.
> How's the fund doing these days? Must still be lower than one
> action item, or we
Given the choice between lisp (lol) and xml, the winner is absolutely clear.
There are even less lisp users than there are Linux users, and that's
a sad statistic.
-tc
On Sat, Sep 4, 2010 at 2:16 PM, Rick Collins wrote:
> At 12:11 AM 9/4/2010, you wrote:
>>
>> On Fri, Sep 03, 2010 at 11:29:58PM
At 12:11 AM 9/4/2010, you wrote:
On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote:
> XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway?
>
For most data, XML ends up being > 50% tags (and < 50% data). It's hard to
read for humans, bandwidth-intensive for machi
On Fri, Sep 03, 2010 at 04:44:14PM -0700, Andrew Poelstra wrote:
>
>However, this also brings the ability to edit PCB components individually,
>which means that some parts could have different layers than others, for
>example. And then you have to deal with layer mappings and stuff and
On Fri, Sep 03, 2010 at 11:29:58PM -0400, Rick Collins wrote:
> XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway?
>
For most data, XML ends up being > 50% tags (and < 50% data). It's hard to
read for humans, bandwidth-intensive for machines, difficult to parse and
general
On Fri, Sep 03, 2010 at 11:00:43PM -0400, DJ Delorie wrote:
>
> Re: functional blocks
>
> If we contemplate changing the PCB file format, it would be nice if we
> went with something that was intrinsically extensible. Knowing that
> the 5th element in a list with '[' means "clearance" is a bad f
XML? What's wrong with XML? Heavy? How heavy are a few electrons anyway?
There is already a preliminary XML based CAD data spec proposed by
IPC, you know, the guys who write specs for the PCB assembly industry...
I don't know if it is the best thing ever invented and I expect the
spec is n
DJ Delorie wrote:
If you'd rather work on the GUI, though, that's also a needed project.
It would be nice if the GTK gui supported all the modern Gnome stuff,
like dockable toolbars and menus-with-icons. The SOW has an entry for
that also.
What level of self proving would Andrew need to do to
1 - 100 of 103 matches
Mail list logo
