subject:"Re\: gEDA\-user\: Functional blocks and PCB format changes"

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, and make the most people happy.
 
 Allow me to toss out JSON.  It is about as light weight as using S-EXP,
 but politically it isn't tied down by references to Lisp.  Plus, since
 it has become fairly popular, there are good readers/writers for most
 languages. 
 
 The format is defined at: http://www.json.org/  
 
 Basically you are allowed strings, numbers, arrays, and object, which
 would be called a map, an associative array, a dictionary, or something 
 else along those lines anywhere else. 


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.

Also, it doesn't require a consistent newline scheme.


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Ethan Swint




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 lines anywhere else.

 

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.

Also, it doesn't require a consistent newline scheme.
   
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!



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Joshua Boyd

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 find that JSON can just as self documenting as XML if used
reasonably.  Reasonably often will mean heavy use of the associative
structure so that fields are clearly labeled with their names. 

YAML might enforce this a bit more though.
 
 Also, it doesn't require a consistent newline scheme.

Yes, if that is important YAML is probably better.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Kai-Martin Knaak

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, it should be friendly to human users. 
In the days of TB hard disks, GB RAM and GHz processor clocks there is no 
need to compromise readability to save some bits. 

---)kaimartin(---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Ouabache Designworks

 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 write a tool
   in perl?
   You grab a xml lib, parse it into a perl data array to do all your work
   and then
   spit it back out as xml when you are finished. You never touch the xml.
   IC design is heading toward using xml  as a means to automate design
   creation.
   If the IP-xact group ever gets their act together you can expect to see
   it extend
   into PCA data as well.
   John Eaton


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 things:

  1. Our most powerful and useful tools haven't changed fundamentally
 in the last 30-40 years, which often means a lot of historical
 oddities.

  2. You can change $IFS or pass flags or insert commands to work around
 newlines if you really want; it's just a PITA.

However, regardless of tool behaviour, it's easier for humans to grok
a format with liberal use of newlines. So this isn't just a case of us
Unix-tards not getting with the times.


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 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,
 but politically it isn't tied down by references to Lisp.  Plus, since
 it has become fairly popular, there are good readers/writers for most
 languages.

 The format is defined at: http://www.json.org/

 Basically you are allowed strings, numbers, arrays, and object, which
 would be called a map, an associative array, a dictionary, or something
 else along those lines anywhere else.


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.

Also, it doesn't require a consistent newline scheme.



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 more concern about this.  I suppose all 
the kayaking I do gives me extra upper body strength. :)


There ain't no free lunch.  Either the file format is easily read by 
humans or it is minimal in size.  You can't have both.  I have never 
heard my computer complain about files being too heavy for it.  I 
will say that I have to use the shoulder strap when I lug it into 
Panera Bread, but I always thought that was because I put so many 
papers in the bag with it.  Maybe it's the files.


Rick



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 more concern about this.  I suppose all the kayaking I do gives 
 me extra upper body strength. :)
 
 There ain't no free lunch.  Either the file format is easily read by humans 
 or it is minimal in size.  You can't have both.

Ah, but usually you get neither these days. The file isn't compact but humans 
can't read it through the fog of flab.

To avoid this, the first thing that's required is to thoroughly understand the 
data being represented. That understanding will influence the file format 
design. Graphics, geometry, and process are different representations.

  I have never heard my computer complain about files being too heavy for it.  
 I will say that I have to use the shoulder strap when I lug it into Panera 
 Bread, but I always thought that was because I put so many papers in the bag 
 with it.  Maybe it's the files.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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.

Why? I'd much rather handwrite XML than YAML.  
And I'd certainly prefer it to the existing file formats, which I can barely 
edit without looking up the meaning of each position.

I'm not sure that I see a good reason for the hatred of XML.  I've never found 
the size of Inkscape documents to be absurd, for example, and the fact that 
python and other languages can manipulate it so easily is definitely a plus.   



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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, 
 and the fact that python and other languages can manipulate it so easily is 
 definitely a plus.   

But Python and other languages can just as easily manipulate line-oriented 
formats, while some very important tools like awk and sed cannot handle HTML.

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.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Phil Frost

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 much rather handwrite XML than YAML.  
 And I'd certainly prefer it to the existing file formats, which I can
 barely edit without looking up the meaning of each position.
 
 I'm not sure that I see a good reason for the hatred of XML.  I've
 never found the size of Inkscape documents to be absurd, for example,
 and the fact that python and other languages can manipulate it so
 easily is definitely a plus.   

Proposing XML without a DTD is like proposing French without any defined
nouns. People hate XML because most DTDs are abysmal. For a reason to
hate XML, I refer you to Apple's plist format.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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://avdi.org/devblog/2009/10/29/simplicity-is-complicated/



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 ratio is
   abysmal.

 Why? I'd much rather handwrite XML than YAML.
 And I'd certainly prefer it to the existing file formats, which I can
 barely edit without looking up the meaning of each position.

 I'm not sure that I see a good reason for the hatred of XML.  I've
 never found the size of Inkscape documents to be absurd, for example,
 and the fact that python and other languages can manipulate it so
 easily is definitely a plus.

Proposing XML without a DTD is like proposing French without any defined
nouns. People hate XML because most DTDs are abysmal. For a reason to
hate XML, I refer you to Apple's plist format.


So the problem is not XML, it's really the DTD?

Rick 




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 
type a.../a,

which is 7 characters of non-data text.


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.




To contrast, in YAML you would have

  a: ...

which is 2 characters, plus indentation, and a lot easier both to 
read and to type.



Practically, consider:
  layernamemy-layer/name/layer

Versus:

  layer:
name: my-layer

The latter is lighter, simpler, grep-able-er, and shows a clear distinction
between data and metadata.


Oh?  I don't see how any of the above follow.  For the most part, I 
don't expect to be writing much XML by hand.  But I do expect to need 
to read it sometimes and less often edit it.  That is, the part where 
the name or other property value is typed will need to be 
changed.  Finding that value quickly and easily is what I am 
interested in.  The computer does a great job of dealing with the 
size and format of the file.  I want to use my eyes to quickly find 
the data I'm interested in.




Machine-generated XML almost never uses whitespace, so it's next to impossible
to determine nesting levels or document validity, not to mention grep and awk
being nearly useless.


The only XML I have seen is indented just as I would indent code.  Is 
there something that would make it hard to output whitespace 
formatted XML?  I would think that would be up to the program.  You 
example above uses no indentation for XML, but uses indentation for 
the counter example.  Is whitespace easier to generate by machine for 
formats other than XML?


Rick 




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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 devices.

This year's iPad has 16 GB flash, minimum.  Suppose that someone ports PCB
to iOS while they still make a 16 GB model (oh-so-likely) and that it were
allowed in the iTunes app store while containing GPL code (wanna buy a
bridge?).

Further suppose that there's a 10X file-size penalty for using XML.  Let's
call the file size a PITA if it reached (say) 10% of that, 1.6 GB. (Can
you even buy a USB drive that small anymore?)

So, the questions: Who here generates PCB files as large as 160 MB on a
regular basis?  And, if you answered me, is this type of design one that
you'd prefer to edit on a small screen?

Seriously.  Does anyone actually think that XML would make a
non-negligible difference one way or another about whether you could run
PCB on any  forthcoming iXYZDroidBerry?  This argument fails the common
sense test.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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
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.seul.org/cgi-bin/mailman/listinfo/geda-user




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Stefan Salewski

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 why should we care about efficient coding -- computers are fast.

And why should we care about screen layout -- monitors are large today.

And why care about energy saving -- we still have some oil and gas.

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 have seen people asking for help in internet forums -- they posted a
JPEG screenshot of a short computer error message -- 50 kByte for 50
Byte of text. They do not care...




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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 that converts the core data into a
common format for the exporters.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

 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 slightly disingenuous.


 I have seen people asking for help in internet forums -- they posted a
 JPEG screenshot of a short computer error message -- 50 kByte for 50
 Byte of text. They do not care...

Your example is at least two orders of magnitude out of proportion.



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Steven Michalske


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.
 
 File size just means a bigger file to generate/parse. 
 
 And why should we care about efficient coding -- computers are fast.

As a performance guy.  this argument leads to poorly thought out code.
 
 And why should we care about screen layout -- monitors are large today.

Not true.  we still have many 13 monitors.
 
 And why care about energy saving -- we still have some oil and gas.

Quit trashing the planet for my kids.
 
 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.

My issues with XML
1.  It is used in way to many cases for data serialization.  It is a 
document, not data storage.
2.  Readability,  properly formatted not too bad, but most xml documents I 
have read are not clearly formatted,  just one long line.
3.  Requires great documentation and specification to be compatible. DTD's 
and other extra stuff.  ( I doubt the developers will prioritize that extra 
work )
4.  I have to write a parser all the functions for each token,  to rip out 
the tokens and such.

I know that i will not write any code for XML if i can avoid it, as most times 
it is the wrong choice.

Now to put this in prospective.  I proposed that footprints be SVG with 
specially named layers.  that could be mapped properly into PCB
Here are my reasons for SVG:  
-   it is an open format with strong support in the industry. 
-   it is well documented. 
-   it has libraries for manipulation.

These strengths overcome 3 and 4,  and slightly overcome 2.

 
 I have seen people asking for help in internet forums -- they posted a
 JPEG screenshot of a short computer error message -- 50 kByte for 50
 Byte of text. They do not care...
 
They don't know better,  teach them, they can learn

 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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; it is the
 /redundant/ filesize. Even for a single-character tag, you need to
 type a.../a,
 which is 7 characters of non-data text.
 
 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.


The concern here is in processing speed, not memory space. XML is very
large and complicated, and supporting it will cost us in code speed and
complexity.
 
 
 To contrast, in YAML you would have
 
   a: ...
 
 which is 2 characters, plus indentation, and a lot easier both to
 read and to type.
 
 
 Practically, consider:
   layernamemy-layer/name/layer
 
 Versus:
 
   layer:
 name: my-layer
 
 The latter is lighter, simpler, grep-able-er, and shows a clear distinction
 between data and metadata.
 
 Oh?  I don't see how any of the above follow.

Really? There's less metadata, a clearer divide between fields and their
names, cleaner spacing and the same amount of information. grep and sed
can handle this with no trickery.

In YAML, the text on the left of the : is the name. The text on the right
is the data. Name-value pairs are separated by newlines.

In XML, the text inside  is the name. The text inside  is the data.
Name-value pairs are also separated by .

  For the most part, I
 don't expect to be writing much XML by hand.  But I do expect to
 need to read it sometimes and less often edit it.  That is, the part
 where the name or other property value is typed will need to be
 changed.  Finding that value quickly and easily is what I am
 interested in.  The computer does a great job of dealing with the
 size and format of the file.  I want to use my eyes to quickly find
 the data I'm interested in.
 

Pop open a .xlsx file and try to edit a few cells. You will find a
ludicrously inefficient file with no whitespace, and will have quite
an adventure editing it when all the data is on one line. YAML (mostly)
requires clean whitespacing and was designed to be edited by humans.

 
 Machine-generated XML almost never uses whitespace, so it's next to 
 impossible
 to determine nesting levels or document validity, not to mention grep and awk
 being nearly useless.
 
 The only XML I have seen is indented just as I would indent code.
 Is there something that would make it hard to output whitespace
 formatted XML?  I would think that would be up to the program.  You
 example above uses no indentation for XML, but uses indentation for
 the counter example.  Is whitespace easier to generate by machine
 for formats other than XML?


Not easier, just done more often.

Open an Office 2007 document, or a generated XHTML file, to see how
ugly XML can be.


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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, which is the major limit for small devices.

This year's iPad has 16 GB flash, minimum.  Suppose that someone ports PCB
to iOS while they still make a 16 GB model (oh-so-likely) and that it were
allowed in the iTunes app store while containing GPL code (wanna buy a
bridge?).

Further suppose that there's a 10X file-size penalty for using XML.  Let's
call the file size a PITA if it reached (say) 10% of that, 1.6 GB. (Can
you even buy a USB drive that small anymore?)


Yes, on the last board order I made the vendor sent me all my design 
files on a 256 MB Flash drive with a keychain attached.  So they are 
still available and obviously inexpensive.  However, the price of 
Flash and DRAM are dropping again, so we may see the smaller units go 
by the wayside soon and be stuck with 2 GB as the smallest Flash 
drive on the market.




So, the questions: Who here generates PCB files as large as 160 MB on a
regular basis?  And, if you answered me, is this type of design one that
you'd prefer to edit on a small screen?

Seriously.  Does anyone actually think that XML would make a
non-negligible difference one way or another about whether you could run
PCB on any  forthcoming iXYZDroidBerry?  This argument fails the common
sense test.


The only reason why I feel XML is a good idea is that there is 
already a standard XML schema that could be used as a starting 
point.  As Windell says, the arguments against XML seem to be based 
on some sort of bias rather than any real facts against it.  But it 
is pretty clear that there is little interest in making the program 
similar to anything else.  Maybe this is not a good idea at all.  It 
was just a thought.


I will say that when people use words like bloat, large, 
complicated, slow, ugly, etc., they are not discussing 
engineering.  They are using emotion to try to influence the 
process.  I just read another post on this topic that is using these 
sorts of words without any clear basis.  There is no point in 
discussing emotionally charged issues.


Rick 




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Steven Michalske

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 bigger file to generate/parse. Doesn't affect RAM
use significantly, which is the major limit for small devices.

This year's iPad has 16 GB flash, minimum. Suppose that someone ports PCB
to iOS while they still make a 16 GB model (oh-so-likely) and that it were
allowed in the iTunes app store while containing GPL code (wanna buy a
bridge?).

Further suppose that there's a 10X file-size penalty for using XML. Let's
call the file size a PITA if it reached (say) 10% of that, 1.6 GB. (Can
you even buy a USB drive that small anymore?)

Yes, on the last board order I made the vendor sent me all my design files on
a 256 MB Flash drive with a keychain attached. So they are still available
and obviously inexpensive. However, the price of Flash and DRAM are dropping
again, so we may see the smaller units go by the wayside soon and be stuck
with 2 GB as the smallest Flash drive on the market.

So, the questions: Who here generates PCB files as large as 160 MB on a
regular basis? And, if you answered me, is this type of design one that
you'd prefer to edit on a small screen?

Seriously. Does anyone actually think that XML would make a
non-negligible difference one way or another about whether you could run
PCB on any forthcoming iXYZDroidBerry? This argument fails the common
sense test.

The only reason why I feel XML is a good idea is that there is already a
standard XML schema that could be used as a starting point. As Windell says,
the arguments against XML seem to be based on some sort of bias rather than
any real facts against it. But it is pretty clear that there is little
interest in making the program similar to anything else. Maybe this is not a
good idea at all. It was just a thought.

I will say that when people use words like bloat, large, complicated,
slow, ugly, etc., they are not discussing engineering. They are using
emotion to try to influence the process. I just read another post on this
topic that is using these sorts of words without any clear basis. There is
no point in discussing emotionally charged issues.

pin:
pinNumber: 2
pinName: rst
x1: 1234
y1: 4321
x2: 2345
y2: 4321
layer: component

or
pinpinNumber2/pinNumberpinNamerst\pinNamex11234\x1y14321\y1x22345\x2y25432\y2layercomponent\layer\pin

I call the second large, bloat, and ugly.

98 chars vs 134 or 36% bigger for a pin with these mythical formats.

now the pin in XML could be cleaned up

pin
pinNumber2/pinNumber
pinNamerst\pinName
x11234\x1
y14321\y1
x22345\x2
y25432\y2
layercomponent\layer
\pin

Slightly better but still ugly

Arguably grep and sed will have issues with both XML or YAML

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 fancy curves, built in layers and
more..

Steve

Rick

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

 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.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

 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 the code is. There are plenty of
good arguments for and against XML. I don't think that file size is one of
them.


 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 fancy curves, built in layers
 and more..

Interesting idea.  Could preview footprints *natively* at gedasymbols.

It *would* be pretty awesome to be able to use SVG graphics for silk
layers.  Fancy curves might work well for future routers as well.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 available tookit? Line-oriented formats don't prevent you 
from using Perl. Gschem's format is a fine example of a format that has short, 
concise documentation, is easy to parse, and is fundamentally as expressive as 
XML. 

 
 Classic is not a point in your favor here.

When Larry Wall learns to write as clearly as Brian Kernighan, I'll agree.

John Doty  Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 fancy curves, built in layers
  and more..
 
 Interesting idea.  Could preview footprints *natively* at gedasymbols.
 
 It *would* be pretty awesome to be able to use SVG graphics for silk
 layers.  Fancy curves might work well for future routers as well.


I don't think SVG is appropriate for storing entire PCBs. There's too
much non-graphical data in .pcb files.

Footprints, yes, that could work.


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Ouabache Designworks

 pin:
  pinNumber: 2
  pinName: rst
  x1: 1234
  y1: 4321
  x2: 2345
  y2: 4321
  layer: component
 or
 pinpinNumber2/pinNumberpinNamerst\pinNamex11234\x1y
 14321\y1x22345\x2y25432\y2layercomponent\layer\pin
 I call the second large, bloat, and ugly.

   -
   Here you go:
   ===
#!/usr/bin/perl  -w
 use strict;
 use warnings;
 my $filename = shift @ARGV;
 use XML::LibXML;
 my $parser = XML::LibXML-new();
 my $doc= $parser-parse_file($filename);
 foreach
 my $pin ($doc-findnodes('/pin')) {
   my($pinNumber)  = $pin-findnodes('./pinNumber/text()')-to_literal
   ;
   my($pinName)= $pin-findnodes('./pinName/text()')-to_literal ;
   my($x1) = $pin-findnodes('./x1/text()')-to_literal ;
   my($y1) = $pin-findnodes('./y1/text()')-to_literal ;
   my($x2) = $pin-findnodes('./x2/text()')-to_literal ;
   my($y2) = $pin-findnodes('./y2/text()')-to_literal ;
   my($layer)  = $pin-findnodes('./layer/text()')-to_literal ;
   print pin\n;
   print   pinNumber: $pinNumber\n;
   print   pinName: $pinName\n;
   print   x1: $x1\n;
   print   y1: $y1\n;
   print   x2: $x2\n;
   print   y2: $y2\n;
   print   layer: $layer\n;
}
   =
   Simple perl script will make things pretty again. (after you fix the
   your backslashes). Only takes
   one extra module (libXML) that you can apt-get on ubuntu.  Going back
   the other way is just as easy once
   you write a parser for your format.
   If size is an issue you can always store everything compressed.  Then
   we can have another argument about
   whether we should create our own compression scheme or use an existing
   one.
   John Eaton


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-13 Thread Steven Michalske

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'))

pprint(pcb)

EOF

./foo.py
{'pin': {'layer': 'component',
 'pinName': 'rst',
 'pinNumber': 2,
 'x1': 1234,
 'x2': 2345,
 'y1': 4321,
 'y2': 4321}}

When I add a new flag to the parser round

#! /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
 round: true
...
''')

pprint(pcb)


./foo_with_round.py
{'pin': {'layer': 'component',
 'pinName': 'rst',
 'pinNumber': 2,
 'round': True,
 'x1': 1234,
 'x2': 2345,
 'y1': 4321,
 'y2': 4321}}

The parser dosen't need a new line
 my($layer)  = $pin-findnodes('./round/text()')-to_boolean ;

Or something like that.

My point about XML vs any data serialization language is that we have a data 
structure in out code that can be just dumped.

With XML we write a parser, with yaml we use a parser that is already written.


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.

On Sep 13, 2010, at 6:57 PM, Ouabache Designworks wrote:

 pin:
  pinNumber: 2
  pinName: rst
  x1: 1234
  y1: 4321
  x2: 2345
  y2: 4321
  layer: component
 or
 pinpinNumber2/pinNumberpinNamerst\pinNamex11234\x1y
 14321\y1x22345\x2y25432\y2layercomponent\layer\pin
 I call the second large, bloat, and ugly.
 
   -
   Here you go:
   ===
#!/usr/bin/perl  -w
 use strict;
 use warnings;
 my $filename = shift @ARGV;
 use XML::LibXML;
 my $parser = XML::LibXML-new();
 my $doc= $parser-parse_file($filename);
 foreach
 my $pin ($doc-findnodes('/pin')) {
   my($pinNumber)  = $pin-findnodes('./pinNumber/text()')-to_literal
   ;
   my($pinName)= $pin-findnodes('./pinName/text()')-to_literal ;
   my($x1) = $pin-findnodes('./x1/text()')-to_literal ;
   my($y1) = $pin-findnodes('./y1/text()')-to_literal ;
   my($x2) = $pin-findnodes('./x2/text()')-to_literal ;
   my($y2) = $pin-findnodes('./y2/text()')-to_literal ;
   my($layer)  = $pin-findnodes('./layer/text()')-to_literal ;
   print pin\n;
   print   pinNumber: $pinNumber\n;
   print   pinName: $pinName\n;
   print   x1: $x1\n;
   print   y1: $y1\n;
   print   x2: $x2\n;
   print   y2: $y2\n;
   print   layer: $layer\n;
}
   =
   Simple perl script will make things pretty again. (after you fix the
   your backslashes). Only takes
oops :-0  see how one can make mistakes  :-P
   one extra module (libXML) that you can apt-get on ubuntu.  Going back
   the other way is just as easy once
   you write a parser for your format.
written already
in perl it is use yaml;  available on cpan

   If size is an issue you can always store everything compressed.

I never really cared about size, gzip of bzip the bugger and you get faster 
load and store times. for what ever format your using.

 Then
   we can have another argument about
   whether we should create our own compression scheme or use an existing
   one.
I vote for quantum 1 bit compression!  this way all designs and files take up 
4KB  ( the block size in most computers to store the file). :-)
and all PCBs ever created are the same file!   Included the first time you save 
the default layout


   John Eaton
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-06 Thread Peter Clifton

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 friend of mine has an iPad I (might) be able to test
on.

Let me guess though.. it doesn't do X11?

-- 
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)



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-05 Thread Bert Timmerman

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 PCB format changes

 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 design, schematic, layout, mechanical, etc, even 
   board lay up.  So the compatibility issue is moot because any one 
   app only needs to deal with the portion that applies to it.  Just 
   don't muck with the other parts.

   The heavy issue is a red herring (are you planning on 
 hosting this 
   on a cell phone maybe?)  No PCB file format is going to 
 be easy for 
   humans to read.  Bandwidth?  Back to the MCU in the cell phone I 
   guess.  Ugly, now there is a great technical argument.

   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?

 This is not an emotional argument, but a technical one, and 
 the choice 
 is not between XML and reinventing the wheel. (Sadly, my Lisp 
 suggestion has been shot down - by better arguments than 
 popularity, I 
 might add. ;) There are other formats to consider, and yes, 
 inventing 
 one might be an option.

 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? 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?

 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 than the file 
 format which only impacts the performance when reading or 
 saving the file.  If we need to work with 1000 layer boards, 
 I expect we would have computers which would be not at all 
 burdened by XML file formats.

 I'm trying to be realistic about the requirements.  I think 
 that the 2x or 3x factor of file size of using something like 
 XML would be lost in the noise.  The advantages of working 
 with an industry standard file format could be very large.  
 Of course as you or someone pointed out, IPC-2511B is not a 
 well established format.  But to my knowledge it is the only 
 one that spans most if not all aspects of circuit board 
 manufacturing.  It seems like a great idea to work with 
 something this useful and I am pretty sure that concerns with 
 using it can be ironed out.

 Unless you want feature-parity with other CAD programs, it is 
 impossible to have file-format-parity. So no matter what, conversion 
 programs will have to be written. Creating similar file 
 formats won't 
 help anything, other than to limit our own format, and potentially 
 cause problems if PCB and another CAD program are able to open (and 
 corrupt) each other's files.

 I don't agree that a common file format has to be 
 restrictive.  If the file format is flexible enough, the 
 program won't be limited.  Everything doesn't have to be 
 included from the start.  I don't know if IPC-2511B is 
 flexible enough for PCB and future ideas for PCB, but using 
 XML I expect it can be expanded easily.  I don't think anyone 
 here has really looked hard at it.  It may well be 
 extensible.  I don't know.  But I would like to at least 
 consider it and not toss it away without giving it a chance.

 Rick 

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 exchangable XML file.

I think that for an exchangable format for schematic capture, pcb layout
__and__ 3D mechanical CAD stuff the problem is waaay to big to grasp in a
forthnight and DIY.

And there happens to be a standard of sorts which does just that, named IDF,
some of the large commercial CAD vendors play this game already.

In this playfield design files with 1MB  size  10MB is not that uncommon
these days.

Welcome in Utopia mate ;-)

Have a look at:

http://www.simplifiedsolutionsinc.com/images/idf_v40_overview.pdf 

http://www.protel.com/files/training/Module%2020%20-%203D%20Mechanical%20CAD
.pdf

http://www.simplifiedsolutionsinc.com/images/idf_v30_spec.pdf

Happy reading ;-)

Kind regards,

Bert Timmerman

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-05 Thread Bert Timmerman

Hi,

There happens to be a newer version (1998) of the IDF specification:

http://www.simplifiedsolutionsinc.com/images/idf_v40_spec.pdf 

Kind regards,

Bert Timmerman

 -Original Message-
 From: geda-user-boun...@moria.seul.org 
 [mailto:geda-user-boun...@moria.seul.org] On 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 
  [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 PCB format changes
  
  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 design, schematic, layout, mechanical, etc, even 
board lay up.  So the compatibility issue is moot 
 because any one 
app only needs to deal with the portion that applies to 
 it.  Just 
don't muck with the other parts.
   
The heavy issue is a red herring (are you planning on
  hosting this
on a cell phone maybe?)  No PCB file format is going to
  be easy for
humans to read.  Bandwidth?  Back to the MCU in the 
 cell phone I 
guess.  Ugly, now there is a great technical argument.
   
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?
   
  
  This is not an emotional argument, but a technical one, and
  the choice
  is not between XML and reinventing the wheel. (Sadly, my Lisp 
  suggestion has been shot down - by better arguments than
  popularity, I
  might add. ;) There are other formats to consider, and yes,
  inventing
  one might be an option.
  
  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? 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?
  
  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 than the file format which only impacts the 
  performance when reading or saving the file.  If we need to 
 work with 
  1000 layer boards, I expect we would have computers which 
 would be not 
  at all burdened by XML file formats.
  
  I'm trying to be realistic about the requirements.  I think 
 that the 
  2x or 3x factor of file size of using something like XML 
 would be lost 
  in the noise.  The advantages of working with an industry standard 
  file format could be very large.
  Of course as you or someone pointed out, IPC-2511B is not a well 
  established format.  But to my knowledge it is the only one 
 that spans 
  most if not all aspects of circuit board manufacturing.  It 
 seems like 
  a great idea to work with something this useful and I am 
 pretty sure 
  that concerns with using it can be ironed out.
  
  
  Unless you want feature-parity with other CAD programs, it is 
  impossible to have file-format-parity. So no matter what, 
 conversion 
  programs will have to be written. Creating similar file
  formats won't
  help anything, other than to limit our own format, and potentially 
  cause problems if PCB and another CAD program are able to open (and
  corrupt) each other's files.
  
  I don't agree that a common file format has to be 
 restrictive.  If the 
  file format is flexible enough, the program won't be limited.  
  Everything doesn't have to be included from the start.  I 
 don't know 
  if IPC-2511B is flexible enough for PCB and future ideas 
 for PCB, but 
  using XML I expect it can be expanded easily.  I don't think anyone 
  here has really looked hard at it.  It may well be extensible.  I 
  don't know.  But I would like to at least consider it and 
 not toss it 
  away without giving it a chance.
  
  Rick
  
  
 
 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 exchangable XML file.
 
 I think that for an exchangable format for schematic capture, 
 pcb layout __and__ 3D mechanical CAD stuff the problem is 
 waaay to big to grasp in a forthnight and DIY.
 
 And there happens to be a standard of sorts which does just 
 that, named IDF, some of the large commercial CAD vendors 
 play

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-05 Thread Bob Paddock

   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 hard, big
   or
   small, depending on the task at hand.
   Specifically related to this discussion is this:
   Create a maintainable extensible XML format
   Reduce change when you design XML formats agile enough to incorporate
   new requirements
   [2]http://www.ibm.com/developerworks/library/x-extensxml.html
   The problems described there are not specific to XML formats.
   XML gives us the ability to interact with other tools.  JSON gives
   smaller file format, with Lots of Irritating Silly Parentheses.  YAML
   gives flexibility, with small file size.  SVG lets us layout boards in
   our browser (I've actually wanted to do that due to restrictive IT
   policies on what software can be installed and used).  The 'What' of a
   requirement document is more important than the 'How'.  No reason at
   all that there can not be multiple file formats, *if* things are
   specified well.
   We all have many wishes, with a fixed amount of time to allocate to
   our lives, unless we make time to code things we'll be spending time
   on wishes and still be where we started in the end.  The Devil's
   weapon of choice today, is distraction from our goals in life.
   Here is my Wish List of sorts:
   Anyone ever consider the heretical idea of tossing it all and start
   over fresh? Lets us get things like hard-metric options as the first
   thing that came to mind.
   There are many external libraries today, for examples many from the
   Boost and wxWdigets domains, that make that idea easier than in the
   past, see below for the easy stuff.
   The hard part is the domain specific stuff, that few of us understand
   berried in 20+ years of accumulated poorly commented cruft.
   DJ is there any hope of creating a library of the domain specific
   stuff?
   For the easy stuff, as long as we don't have a Not Invented Here
   complex or external dependencies make it hard to build
   [3]et.al. problems (reinventing the wheel just takes valuable
   development
   time to make a lot of incompatible wheels):
   Polygon library: Booleans/clipping, resizing/offsetting and more
   for planar polygons with integral coordinates.
   [4]http://www.boost.org/doc/libs/1_44_0/libs/polygon/doc/index.htm
   Interprocess: handling to Schematics for real time interaction.
   [5]http://www.boost.org/doc/libs/release/doc/html/interprocess.html
   Quaternion Math: Gets around accumulating errors when rotating objects
   in six-degrees-of-freedom (See Stewart Platforms), when we go 3D
   someday.
   [6]http://www.boost.org/doc/libs/release/libs/math/doc/quaternion/html/
   index.html
   MPI: Message Passing Interface library, for use in distributed-memory
   parallel application programming, for that 1000 layer board (that no
   one could ever build, lets be realistic in requirements).
   [7]http://www.boost.org/doc/libs/release/doc/html/mpi.html
   Parameter Library: Write functions that accept arguments by name.
   [8]http://www.boost.org/doc/libs/release/libs/parameter/doc/html/index.
   html
   Program Options: The program_options library allows program developers
   to obtain program options, that is (name, value) pairs from the user,
   via conventional methods such as command line and config file,
   environment variables.
   [9]http://www.boost.org/doc/libs/release/doc/html/program_options.html
   Property Tree: A tree data structure especially suited to storing
   configuration data.
   [10]http://www.boost.org/doc/libs/release/libs/property_tree/index.html
   Pyton (for scripting): The Boost Python Library is a framework for
   interfacing Python
   and C++. It allows you to quickly and seamlessly expose C++ classes
   functions and objects to Python, and vice-versa, using no special
   tools -- just your C++ compiler.
   I'd do something with Lua myself actually, see below.
   [11]http://www.boost.org/doc/libs/release/libs/python/doc/index.html
   Signals2: Managed signals and slots callback implementation
   (thread-safe version 2), for plug-in implementations.
   [12]http://www.boost.org/doc/libs/release/libs/signals2/
   System: Operating system support, including the diagnostics support
   that will be part of the C++0x standard library.
   [13]http://www.boost.org/doc/libs/release/libs/system/doc/index.html
   Boost also has several Smart Pointers, several Parsers, Exception
   handling, Threads and other techniques to make robust code.
   See the whole list here: [14]http://www.boost.org/doc/libs/
   For the GUI I'd use wxWidgets [15]http://www.wxwidgets.org/ which in
   time
   will run on your iWhatsit, and does run on PC, Mac, Unix [16]et.al,
   today.
   Use OpenGL for the machines with the power to use it where 'expensive'

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-05 Thread Bert Timmerman

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 PCB format changes

 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.

 http://www.ibm.com/developerworks/xml/ XML can be easy or 
 hard, big or small, depending on the task at hand.

 Specifically related to this discussion is this:

 Create a maintainable extensible XML format Reduce change 
 when you design XML formats agile enough to incorporate new 
 requirements

 http://www.ibm.com/developerworks/library/x-extensxml.html

 The problems described there are not specific to XML formats.

 XML gives us the ability to interact with other tools.  JSON 
 gives smaller file format, with Lots of Irritating Silly 
 Parentheses.  YAML gives flexibility, with small file size.  
 SVG lets us layout boards in our browser (I've actually 
 wanted to do that due to restrictive IT policies on what 
 software can be installed and used).  The 'What' of a 
 requirement document is more important than the 'How'.  No 
 reason at all that there can not be multiple file formats, 
 *if* things are specified well.

 We all have many wishes, with a fixed amount of time to 
 allocate to our lives, unless we make time to code things 
 we'll be spending time on wishes and still be where we 
 started in the end.  The Devil's weapon of choice today, is 
 distraction from our goals in life.

I think we are (hopefully) on the same page.

Let's keep what we already have: pcb's internal engine, maybe some day to be
metrified and an extended and improved file format to be fit for the future.

To me XML would be an intermediate file, used to exchange data, the same
purpose an IDF file would have.

Reinventing the XML wheel would take more effort for us and other parties,
someone would have to think-up a XSD schema.

The IDF format is well defined, version 4.0 so the big issues should be
solved, some mechanical 3D CAD vendors (mainstream) have picked up the
format as hae some big EDA players.

The worst thing that could happen is someone writing a plug-in or an
exporter for either XML or IDF ;-)

The same goes for a IPC-356 compliant test point data exporter, a DXF import
plug-in, a DXF exporter and the list goes on and on.

Too much ideas and sparse free time.

Just my EUR 0.02

Kind regards,

Bert Timmerman.

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-05 Thread Andrew Poelstra

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 a footprint or via
 
 It allows for references. So all vias of a type could point to the
 same data and then we only would have to change one data structure
 to change all of the vias with the same tag.
 
 There is a c library libyaml.
 
 And many other languages have libraries,  perl python ruby and many
 more.  Although I did not see an official lisp library.
 

I've glanced through the YAML wikipedia page and it looks pretty good.
I'd vote for it, anyway.

 But before we pick a file format we need to decide what we want to
 store. And then choosing how we want to store it.


I'm not sure this is true. We know what we need to store in a vague
sense - traces and components, footprints and layers, DRC rules and
netlists. Any decently-extensible language should let us add things
as needed.


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-05 Thread Andrew Poelstra

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 Layer 3 are coincedentally tagged with the rule.
  
  What if the user then decides he wants the rule to apply to Layer 4
  instead?
 
 In that specific case, we could apply rules to layers as well as
 objects, but I see your point.
 
 Unfortunately, the math behind DRC is expensive, so generalizing the
 rules needs to mesh well with doing the math only once.


I'm not sure that storing DRC rules as filters (rather than tagging
data) would slow things down significantly. Internally, we could still
maintain a tag structure. We would need to keep it in sync when adding
or removing components or rules, of course, and when loading .pcb files.

But when running the DRC, there would be no cost to storing the rules
this way.


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread gedau

On Sat, Sep 04, 2010 at 01:16:01AM -0400, Rick Collins wrote:

snip

 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?

 Rick 

Please note: I am not saying this for or against XML. I just felt like 
the above sentences implied using a specific file format is an ultimate 
solution for compatibility. Please always read XML as any standard 
or widespread format, text or binary, for example json, plist, sql 
dumps, whatever.

Using xml as file format for PCB (or any CAD program) will not 
automatically make it compatible with any other CAD program. I see two 
different things here.

1. Use a file format that is well documented and known (this can be 
a standard format like XML, json, plist, or a custom format with proper 
documentation).
2. How the content is actually represented. 

Point 1. is a basis, a must. Without that, we can not talk about making 
two programs compatible, since the data can not be read or written by 
the other program. However, just being able to read the file, but not 
understanding what they mean, won't make any compatibility. Thus point 
2. is a must too.

XML may or may not be a good solution for 1., but doesn't do _anything_ 
to 2. The current file format is plain text and documented enough 
(in worst case by the source code) that any developer has the chance to 
parse or generate it, this it also fulfills the reqiurements in 1.

Switching (or not switching) to XML will not make a real difference 
in compatibility. Switching to any standard format may ease 
implementation as one doesn't need to write a custom parser. But don't 
overestimate this part either: using a parser generator helps a lot, 
and even going without that, I strongly believe that finally the real 
complex and big part of the work is 2., not 1. Making two CAD 
programs compatible is harder on the how we represent the design 
internally level than how do we convert the representation to an 
actual file format.

Regards,

Tibor Palinkas






___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Philipp Klaus Krause

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 best thing ever invented and I expect the spec
is not complete enough for everyone to make their data files 100%
compatible without a lot of communication, but wouldn't it be a great
idea to at least start on a path which could result in a common data
base for CAD packages? What a concept! The spec I have seen that looks
like it would apply is IPC-2511B. These things don't seem to be free,
but I found this one somewhere, maybe on the IPC site.

Rick

There are some standards (IPC-2511B, IPC-2511A, IPC-2511-1, IPC-2511-2,
IPC-2511-3) at http://webstds.ipc.org/2511/2511intro.htm

http://www.google.de/url?sa=tsource=webcd=10ved=0CE0QFjAJurl=http%3A%2F%2Fwww.ipc.org%2F4.0_Knowledge%2F4.1_Standards%2FSpecTree.pdfrct=jq=IPC-2511ei=7veBTPvfG8aOswbSypTmCAusg=AFQjCNHHckOZXnmnwkjb51O54CMh0RGDxwcad=rja
tries to map the standards world (design track on the right side is
probably what we're interested in).
Goggling the standard's names seems to suggest that these standards have
found some adaption in other tools.
ICP-2581 (with it's sectional requirements IPC-2582 to IPC-2588) is the
latest; from a quick glance it doesn't look like XML though. IPC-2511B
was the only XML one I noticed.

Philipp

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Ineiev

Hello, DJ;

On 9/4/10, DJ Delorie d...@delorie.com 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.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 have meta-rules like signal-line-rule or 12vac rule.
 Without a tag, you'd get synthetic tags like line-rule or
 pin-rule.


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 user then decides he wants the rule to apply to Layer 4
instead?


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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, mechanical, etc, even
 board lay up.  So the compatibility issue is moot because any one
 app only needs to deal with the portion that applies to it.  Just
 don't muck with the other parts.
 
 The heavy issue is a red herring (are you planning on hosting this
 on a cell phone maybe?)  No PCB file format is going to be easy for
 humans to read.  Bandwidth?  Back to the MCU in the cell phone I
 guess.  Ugly, now there is a great technical argument.
 
 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?


This is not an emotional argument, but a technical one, and the
choice is not between XML and reinventing the wheel. (Sadly, my
Lisp suggestion has been shot down - by better arguments than
popularity, I might add. ;) There are other formats to consider,
and yes, inventing one might be an option.

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? 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?

Unless you want feature-parity with other CAD programs, it
is impossible to have file-format-parity. So no matter what,
conversion programs will have to be written. Creating similar
file formats won't help anything, other than to limit our own
format, and potentially cause problems if PCB and another CAD
program are able to open (and corrupt) each other's files.


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 and bottom layers (whatever they are) on the PCB that the footprint
is being used in?


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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 user then decides he wants the rule to apply to Layer 4
 instead?

In that specific case, we could apply rules to layers as well as
objects, but I see your point.

Unfortunately, the math behind DRC is expensive, so generalizing the
rules needs to mesh well with doing the math only once.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread John Griessen


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 if the user then decides he wants the rule to apply to Layer 4
instead?


I see having attribs define state for the whole board.  If you change your mind,
you would use the same script that you used to select a set of objects, then
delete the unwanted attrib, or overwrite it.  You need to search the whole 
design
for attribs, since they may have moved along with their object to a new layer...

I can't see a system of tracking how things are applied, just how they are now.
In other words, use GUI and scripts to make selections, then change attribs.
Do the same generic steps to add attribs as to delete.

Which means it would be nice to have a GUI selection by area be well defined
so action commands can refine the selection further.  Right now we have various
selected sets defined, but not sure how general that is.

John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread John Griessen


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 maybe be able to print a machine capable of running gschem and pcb
with machines that are affordable by local shared fablabs or on a hobby budget
in say, ten years?  fifteen?  Depending...

Wish I had some expendable man-months-money to hire all the developers on the 
list today.

John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Windell H. Oskay


On Sep 4, 2010, at 4:30 AM, Ineiev wrote:

 Hello, DJ;
 
 On 9/4/10, DJ Delorie d...@delorie.com 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 arcs, myself.  I discovered it 
when doing some simple tests of the toporouter-- certain arcs produce DRC 
errors when there clearly is none-- says that there isn't 10 mils of clearance 
when there obviously is much more than that.

Here's a minimal test case that demonstrates the errors:   
http://evilmadscientist/source/temp/topo_puzzle.pcb


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Windell H . Oskay

 
 On Sep 4, 2010, at 4:30 AM, Ineiev wrote:
 
 Hello, DJ;
 
 On 9/4/10, DJ Delorie d...@delorie.com 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 arcs, myself.  I discovered 
 it when doing some simple tests of the toporouter-- certain arcs produce DRC 
 errors when there clearly is none-- says that there isn't 10 mils of 
 clearance when there obviously is much more than that.

Doh!  Bad link.  Correct one is:   
http://evilmadscientist.com/source/temp/topo_puzzle.pcb


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Dietmar Schmunkamp

-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 . . .
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 

I showd a geda schematic and the pcb board layout on my Nokia N900
(debian based) to my colleagues at work and they were impressed. I'm not
saying that it's useful to do EDA work on a smartphone, in my case it
was more or less a fun project raising the question Can you do that
with your iPhone?. Nevertheless I was really impressed how easy it was
to install the geda + pcb suite to my smartphone.

The other valid question would be Can you do this with your $$$ eda
application :-) .

- -- 

Mit freundlichen Gruessen

Dietmar Schmunkamp
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkyCvZoACgkQn22l+QvEah3fxQCeO84y3Cuz83Hev3cYp1YJZndL
awsAn1xalA6/rivS4bUKPSjjQj2EIIws
=fMqF
-END PGP SIGNATURE-


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Rick Collins


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 design, schematic, layout, mechanical, etc, even
 board lay up.  So the compatibility issue is moot because any one
 app only needs to deal with the portion that applies to it.  Just
 don't muck with the other parts.

 The heavy issue is a red herring (are you planning on hosting this
 on a cell phone maybe?)  No PCB file format is going to be easy for
 humans to read.  Bandwidth?  Back to the MCU in the cell phone I
 guess.  Ugly, now there is a great technical argument.

 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?


This is not an emotional argument, but a technical one, and the
choice is not between XML and reinventing the wheel. (Sadly, my
Lisp suggestion has been shot down - by better arguments than
popularity, I might add. ;) There are other formats to consider,
and yes, inventing one might be an option.

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? 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?


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 than the file format which only impacts the 
performance when reading or saving the file.  If we need to work with 
1000 layer boards, I expect we would have computers which would be 
not at all burdened by XML file formats.


I'm trying to be realistic about the requirements.  I think that the 
2x or 3x factor of file size of using something like XML would be 
lost in the noise.  The advantages of working with an industry 
standard file format could be very large.  Of course as you or 
someone pointed out, IPC-2511B is not a well established format.  But 
to my knowledge it is the only one that spans most if not all aspects 
of circuit board manufacturing.  It seems like a great idea to work 
with something this useful and I am pretty sure that concerns with 
using it can be ironed out.




Unless you want feature-parity with other CAD programs, it
is impossible to have file-format-parity. So no matter what,
conversion programs will have to be written. Creating similar
file formats won't help anything, other than to limit our own
format, and potentially cause problems if PCB and another CAD
program are able to open (and corrupt) each other's files.


I don't agree that a common file format has to be restrictive.  If 
the file format is flexible enough, the program won't be 
limited.  Everything doesn't have to be included from the start.  I 
don't know if IPC-2511B is flexible enough for PCB and future ideas 
for PCB, but using XML I expect it can be expanded easily.  I don't 
think anyone here has really looked hard at it.  It may well be 
extensible.  I don't know.  But I would like to at least consider it 
and not toss it away without giving it a chance.


Rick 




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Dietmar Schmunkamp

-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 still working on this.)
 
 Mostly I am doing GUI work, since that is more-or-less stateless; I can
 spend 20 minutes reading docs or GTK code and not worry about making it
 work with PCB.
 
 
 But for the underlying logic:
 
 Naturally, I want to avoid any breaking changes to the PCB format, both
 to increase the chances of my code being accepted, as well as the obvious
 compatibility reasons.
 
 So I have a few thoughts:
 
 1. Initially my plan was to tag every object in the PCB with a functional
block. This would make attaching multiple tags easy, though it might
bloat the file, and would be slow to initially parse and search.
 
 
 2. Another idea would be to create functional blocks as recursive PCBs.
This has been mentioned a few times on the list, and creates all sorts
of exciting possibilities - from importing recursive schematics to
reusing layout parts to clearer source control of PCBs.
 
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 it's
a huge complicated mess, both for the user and in the code.
 
 
 What do you guys think I should do? What would require the fewest changes
 to the PCB format, if any?
 
 Generalized DRC rules at least could be tacked on anywhere and would be
 quietly ignored by old versions of pcb, right?
 
 
 Andrew
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 

Andrew,

here are my thoughts about DRC:

There are (at least) 2 contributors to what should be checked by DRC:

1. The obvious one: The capabilities of the manufaturer, e.g. min trace
width = 4 mil, min distance = 4 mil, min drill .
2. The usage pattern: Traces where you expect high current (Vdd, GND,
...) can't use the minimum trace width, while traces that carry high
voltages (and need to meet UL, VDE specs) can't have the minimum distance.

A conclusion of the above is that the DRC rules are on a net base
(potentially on a layer base, if you forece nets with a similiar DRC
requirement to the same layer (sharing the copper with otherlayers).
I see 4 roout styles in the defualt PCB, they could be used to work
around a net specific definition.
- From my point of view, there should be a way of defining net attributes
from geda (see thread wishful UI).

If you want to exetend the DRC capabilites things like handling of
differenatial pairs, comparing netlenghs of busses comes to my mind.

Going slightly off-topic, one goal would be to extract all physical
parameters of a board (RLC for each net segment) and feed that back into
a simulation (spice, gnucap, ...).

- -- 

Mit freundlichen Gruessen

Dietmar Schmunkamp


PS: I won't have internet access for ht next 2 days, I'll comment
responses on Tuesday.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ
TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk
=Y576
-END PGP SIGNATURE-


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Rick Collins

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 you want to read my post regarding this go to http://freepcb.com/ 
and visit the forum, Bug Reports, Design Rule Checking.  The last 
post has a PDF attached.


Rick


At 06:41 PM 9/4/2010, you wrote:

-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 still working on this.)

 Mostly I am doing GUI work, since that is more-or-less stateless; I can
 spend 20 minutes reading docs or GTK code and not worry about making it
 work with PCB.


 But for the underlying logic:

 Naturally, I want to avoid any breaking changes to the PCB format, both
 to increase the chances of my code being accepted, as well as the obvious
 compatibility reasons.

 So I have a few thoughts:

 1. Initially my plan was to tag every object in the PCB with a functional
block. This would make attaching multiple tags easy, though it might
bloat the file, and would be slow to initially parse and search.


 2. Another idea would be to create functional blocks as recursive PCBs.
This has been mentioned a few times on the list, and creates all sorts
of exciting possibilities - from importing recursive schematics to
reusing layout parts to clearer source control of PCBs.

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 it's

a huge complicated mess, both for the user and in the code.


 What do you guys think I should do? What would require the fewest changes
 to the PCB format, if any?

 Generalized DRC rules at least could be tacked on anywhere and would be
 quietly ignored by old versions of pcb, right?


 Andrew



 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


Andrew,

here are my thoughts about DRC:

There are (at least) 2 contributors to what should be checked by DRC:

1. The obvious one: The capabilities of the manufaturer, e.g. min trace
width = 4 mil, min distance = 4 mil, min drill .
2. The usage pattern: Traces where you expect high current (Vdd, GND,
...) can't use the minimum trace width, while traces that carry high
voltages (and need to meet UL, VDE specs) can't have the minimum distance.

A conclusion of the above is that the DRC rules are on a net base
(potentially on a layer base, if you forece nets with a similiar DRC
requirement to the same layer (sharing the copper with otherlayers).
I see 4 roout styles in the defualt PCB, they could be used to work
around a net specific definition.
- From my point of view, there should be a way of defining net attributes
from geda (see thread wishful UI).

If you want to exetend the DRC capabilites things like handling of
differenatial pairs, comparing netlenghs of busses comes to my mind.

Going slightly off-topic, one goal would be to extract all physical
parameters of a board (RLC for each net segment) and feed that back into
a simulation (spice, gnucap, ...).

- --

Mit freundlichen Gruessen

Dietmar Schmunkamp


PS: I won't have internet access for ht next 2 days, I'll comment
responses on Tuesday.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAkyCyxIACgkQn22l+QvEah2PAwCeLQsgUm4urwLKxNah0S9uIciZ
TV8AoJiLd2dH/pZ/Fy+yWvSuoNdT+bZk
=Y576
-END PGP SIGNATURE-


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 than the file format which only impacts the
 performance when reading or saving the file.  If we need to work
 with 1000 layer boards, I expect we would have computers which would
 be not at all burdened by XML file formats.


I don't see any value in making PCB work on cell phones, but we shouldn't
unnecessarily preclude it. Certainly I don't believe the benefit of XML
would outweigh the costs.

Right now I am working on my laptop, which has no personal data on it;
my entire /home is located on the server in my basement, mounted via
SSHFS. Over a gigabit link this is fine; over wireless, opening large
files is a relatively big deal. On a fast enough link, the CPU load
for the encryption is the bottleneck.

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).

Plus, even if individual file bloat is something we can ignore, what
happens when you have thousands or millions of files in source control
or in backups?
 
 I'm trying to be realistic about the requirements.  I think that the
 2x or 3x factor of file size of using something like XML would be
 lost in the noise.  The advantages of working with an industry
 standard file format could be very large.  Of course as you or
 someone pointed out, IPC-2511B is not a well established format.
 But to my knowledge it is the only one that spans most if not all
 aspects of circuit board manufacturing.  It seems like a great idea
 to work with something this useful and I am pretty sure that
 concerns with using it can be ironed out.
 

The problem is that there /isn't/ a useful industry standard format.
If one appears, there is no guarantee that it will be long-lived or
widely-adopted. Better we have a file format that works well for what
we want to do, and use exporters for compatibility.


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread Bob Paddock

 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-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread kai-martin knaak

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 
already almost grind to halt because of it. 


 Plus, even if individual file bloat is something we can ignore, what
 happens when you have thousands or millions of files in source control
 or in backups?

How would XML lead to millions of files?

 
 The problem is that there /isn't/ a useful industry standard format.

Like it or not, XML _is_ an industry standard. A standard for highly 
structured data formats. There is a reason why it is adopted by so 
many projects. The availability of well tested parser code is just
one of them.


 If one appears, there is no guarantee that it will be long-lived or
 widely-adopted.

XML is a good candidate for both. It already enjoys wide spread
adoption. Many of them with high profile like SVG, DocBook, or
OpenStreetMap. See
http://en.wikipedia.org/wiki/List_of_XML_markup_languages


 Better we have a file format that works well for what
 we want to do, and use exporters for compatibility.

This does not preclude XML. XML is not a format by itself,
but just a framework of rules to define a format. If there
are features that are too heavy for your taste, just don't 
use them in your specific instance of XML conform format.

---)kaimartin(---
-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 capacity).
 
 This kind of argument goes against any change. geda development 
 already almost grind to halt because of it. 

 ...
 
  Plus, even if individual file bloat is something we can ignore, what
  happens when you have thousands or millions of files in source control
  or in backups?
 
 How would XML lead to millions of files?
 

XML brings with it an enormous cost in terms of file size and parsing speed.
There will be millions of files regardless. But with a million files, every
kilobyte of bloat becomes a gigabyte of bloat.

We could use a zipped-XML format and avoid the filesize problems, but then
we make script-parsability a lot harder.

Actually, using any whitespace-independent format makes script-parsability
harder, since tools such as grep or sed treat newlines specially. Also,
comments are harder to insert.


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes






On Sep 3, 2010, at 9:11 PM, Andrew Poelstra as...@sfu.ca 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 machines, difficult to parse and
 generally ugly.
 
 Plus, the entire spec is enormous, and using only a subset of the spec
 means that we've lost a lot of the compatibility arguments in favor of
 it.
 
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 a footprint or 
via

It allows for references. So all vias of a type could point to the same data 
and then we only would have to change one data structure to change all of the 
vias with the same tag.

There is a c library libyaml.

And many other languages have libraries,  perl python ruby and many more.  
Although I did not see an official lisp library.

But before we pick a file format we need to decide what we want to store. And 
then choosing how we want to store it.

  I am a fan of backwards and forwards compatible file formats.  And if a file 
is a later version than we support then we should warn and only error if we 
encounter a difference that matters.  Example the new polygon changes only 
break older versions of pcb if they are used.  It would be nice if the parser 
knew what the minimum version of the format was required to store the design.   
Eg it uses pins pads and polygons,  then it is version 2.0. If it used a 
polygon hole it's version 2.3,  etc...

Steve
 
 Andrew
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes






On Sep 3, 2010, at 9:45 PM, Andrew Poelstra as...@sfu.ca 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. And then you have to deal with layer mappings and stuff and it's
   a huge complicated mess, both for the user and in the code.
 
 
 For layer mappings, things don't necessarily have to be difficult. Especially
 if we had a good file format, people could write their own scripts if they
 want to do crazy things.
 
 In the meantime, we could:
 
 
 1. Refuse to export-as-footprints any PCB with more than one copper layer.
   This will likely eliminate the most common problems.
 
Disallows for edge connectors that have an a and b side.

 2. As for PCB components that are themselves PCBs (ie, recursive PCBs), we
   could present the user with a mapping dialog when he tries to import a
   sub-PCB.
 
 
 The dialog would look something like (when importing a 6-layer sub-PCB
 into a 5-layer PCB):
 
 
  Imported PCB   Current PCB
Silk   -- Silk
Top-- Top
Layer One  -- Layer One
Layer Two  -- Layer Two
Layer Three-- Bottom
Bottom -- *New Layer...*
 
 
 The left-hand column is read-only. The right-hand column consists of
 drop-down boxes listing all the existing layers. Selecting *New Layer...*
 would pop up the New Layer dialog.
 
 We could even store this mapping information in the .pcb file and allow
 the user to change it after-the-fact.
 
 
I like this idea.

 Andrew
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes






On Sep 4, 2010, at 8:49 AM, Andrew Poelstra as...@sfu.ca 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 design, schematic, layout, mechanical, etc, even
 board lay up.  So the compatibility issue is moot because any one
 app only needs to deal with the portion that applies to it.  Just
 don't muck with the other parts.
 
 The heavy issue is a red herring (are you planning on hosting this
 on a cell phone maybe?)  No PCB file format is going to be easy for
 humans to read.  Bandwidth?  Back to the MCU in the cell phone I
 guess.  Ugly, now there is a great technical argument.
 
 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?
 
 
 This is not an emotional argument, but a technical one, and the
 choice is not between XML and reinventing the wheel. (Sadly, my
 Lisp suggestion has been shot down - by better arguments than
 popularity, I might add. ;) There are other formats to consider,
 and yes, inventing one might be an option.
 
 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? 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?
 
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

 Unless you want feature-parity with other CAD programs, it
 is impossible to have file-format-parity. So no matter what,
 conversion programs will have to be written. Creating similar
 file formats won't help anything, other than to limit our own
 format, and potentially cause problems if PCB and another CAD
 program are able to open (and corrupt) each other's files.
 
 
 Andrew
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-04 Thread timecop

   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 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, mechanical, etc, even
board lay up. So the compatibility issue is moot because any one
app only needs to deal with the portion that applies to it. Just
don't muck with the other parts.
   
The heavy issue is a red herring (are you planning on hosting
   this
on a cell phone maybe?) No PCB file format is going to be easy for
humans to read. Bandwidth? Back to the MCU in the cell phone I
guess. Ugly, now there is a great technical argument.
   
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?
   
   
This is not an emotional argument, but a technical one, and the
choice is not between XML and reinventing the wheel. (Sadly, my
Lisp suggestion has been shot down - by better arguments than
popularity, I might add. ;) There are other formats to consider,
and yes, inventing one might be an option.
   
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? 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?
   
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
   
Unless you want feature-parity with other CAD programs, it
is impossible to have file-format-parity. So no matter what,
conversion programs will have to be written. Creating similar
file formats won't help anything, other than to limit our own
format, and potentially cause problems if PCB and another CAD
program are able to open (and corrupt) each other's files.
   
   
Andrew
   
   
   
___
geda-user mailing list
[3]geda-u...@moria.seul.org
[4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
   
   
___
geda-user mailing list
[5]geda-u...@moria.seul.org
[6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   1. mailto:smichal...@gmail.com
   2. mailto:as...@sfu.ca
   3. mailto:geda-user@moria.seul.org
   4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
   5. mailto:geda-user@moria.seul.org
   6. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes






On Sep 4, 2010, at 6:00 PM, kai-martin knaak k...@familieknaak.de 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).
 
 This kind of argument goes against any change. geda development 
 already almost grind to halt because of it. 
 
 
 Plus, even if individual file bloat is something we can ignore, what
 happens when you have thousands or millions of files in source control
 or in backups?
 
 How would XML lead to millions of files?
 
 
 The problem is that there /isn't/ a useful industry standard format.
 
 Like it or not, XML _is_ an industry standard. A standard for highly 
 structured data formats. There is a reason why it is adopted by so 
 many projects. The availability of well tested parser code is just
 one of them.
 
 
 If one appears, there is no guarantee that it will be long-lived or
 widely-adopted.
 
 XML is a good candidate for both. It already enjoys wide spread
 adoption. Many of them with high profile like SVG, DocBook, or
 OpenStreetMap. See
 http://en.wikipedia.org/wiki/List_of_XML_markup_languages
 
I once proposed that we use SVG as the footprint format and making layers in 
the SVG represent the proper layer. Then footprints are automatically drawable 
by modern web browsers.

 
 Better we have a file format that works well for what
 we want to do, and use exporters for compatibility.
 
 This does not preclude XML. XML is not a format by itself,
 but just a framework of rules to define a format. If there
 are features that are too heavy for your taste, just don't 
 use them in your specific instance of XML conform format.
 
 ---)kaimartin(---
 -- 
 Kai-Martin Knaak
 Öffentlicher PGP-Schlüssel:
 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53
 
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

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 time...@gmail.com wrote:

   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 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, mechanical, etc, even
 board lay up. So the compatibility issue is moot because any one
 app only needs to deal with the portion that applies to it. Just
 don't muck with the other parts.
 
 The heavy issue is a red herring (are you planning on hosting
   this
 on a cell phone maybe?) No PCB file format is going to be easy for
 humans to read. Bandwidth? Back to the MCU in the cell phone I
 guess. Ugly, now there is a great technical argument.
 
 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?
 
 
 This is not an emotional argument, but a technical one, and the
 choice is not between XML and reinventing the wheel. (Sadly, my
 Lisp suggestion has been shot down - by better arguments than
 popularity, I might add. ;) There are other formats to consider,
 and yes, inventing one might be an option.
 
 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? 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?
 
 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
 
 Unless you want feature-parity with other CAD programs, it
 is impossible to have file-format-parity. So no matter what,
 conversion programs will have to be written. Creating similar
 file formats won't help anything, other than to limit our own
 format, and potentially cause problems if PCB and another CAD
 program are able to open (and corrupt) each other's files.
 
 
 Andrew
 
 
 
 ___
 geda-user mailing list
 [3]geda-u...@moria.seul.org
 [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 
 
 ___
 geda-user mailing list
 [5]geda-u...@moria.seul.org
 [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 
 References
 
   1. mailto:smichal...@gmail.com
   2. mailto:as...@sfu.ca
   3. mailto:geda-user@moria.seul.org
   4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
   5. mailto:geda-user@moria.seul.org
   6. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
 
 
 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread John Griessen


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 it's
   a huge complicated mess, both for the user and in the code.


Dang!  It IS a huge complicated mess.  But then, you could not try to please 
all,
and it can simplify down to use some external script to do remappings of
reused components that have different layers,  and the excitement pops
right back up.

JG

--
Ecosensory   Austin TX


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


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 format,
but seeing clearance=5mil in a list of attributes is much better.
We use something suitable as our menu resource, but folks have argued
for XML too.  I don't want to bring in something as heavy and complex
as XML, but maybe a small parser like our resource parser that just
happened to use XML format would buy us some usefulness at low cost.

For performance reasons, it might be useful to have both an ASCII and
a compiled binary format for these, with a converter.  I've done stuff
like this before; parsing a huge ascii file is a CPU hog compared to
something designed to be digested by a program.

Note we already have the ability to store attributes at the layout,
layer, and element level.  Perhaps that would be one place to hold new
DRC rules?  If we tagged the rulesets, we could then assign those tags
to objects on the board, although storing such tags means a file
format change.  Maybe the new format can specify mandatory stuff as
the first few non-tagged values (like line start/end coordinates) and
have everything else be tagged after that (like clearance=1mm) so it's
more free-form?  We'd need some meta-rules for specifying defaults.

Re: DRC

Our DRC engine could use a complete rewrite.  It doesn't get arcs
right, for example.  It would be nice if it told us the *actual*
design rules used (what's the closest cross-net spacing?  Smallest
drill?  Etc) too.

Re: recursive PCBs

I think the first step in this type of change is to tag layers by
type.  I've spec'd this out before, I think, and it's the Upgrade of
layer and design objects in our big statement of work (SOW):

http://www.geda.seul.org/wiki/geda:pcb_funding_sow

Those items are approximately in do-in-this-order order, but the GUI
stuff can go anywhere.  Anyway, layer design tags each layer with a
type, such as top side silk or inner keepout (a combination of a
where and a what, and optional invert).

This is the basis for elements-as-pcbs and nested pcbs.  The tricky
part is not the data structures, but mapping the various layers in
each submodule.  For example, if you imported a two-layer board module
into a four-layer board, what happens?  Or an element description with
keepaway on all inner layers, how does that map to a six-layer
board?  Etc.

Some of that work can be made easier to code if we switch to C++
officially so we can use a real OO language instead of the OO hack we
currently have.  There's a patch in the tracker to make the code
C++-compatible, someone (i.e. me) needs to review it so we can get it
committed and start seeing who'll have problems if we switch to C++.

Then you could have each object know how to draw itself (or part of
itself, usually by layers) just by foo-draw().  I don't think this is
*needed* though.  We just need a new object type that is itself a PCB
(or at least the PCB-Data structure, like a Buffer), a way to nest
all the draw/find/select etc stuff, and a way to tell the GUI which
object(s) you're editing.  That automatically gives you a footprint
editor too :-)

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.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread John Griessen


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 be eligible for
Linux Fund payment?  How's the fund doing these days?  Must still be lower
than one action item, or we would have heard, I bet.

John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread 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 best thing ever invented and I expect the 
spec is not complete enough for everyone to make their data files 
100% compatible without a lot of communication, but wouldn't it be a 
great idea to at least start on a path which could result in a common 
data base for CAD packages?  What a concept!  The spec I have seen 
that looks like it would apply is IPC-2511B.  These things don't seem 
to be free, but I found this one somewhere, maybe on the IPC site.


Rick


At 11:00 PM 9/3/2010, you 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 format,
but seeing clearance=5mil in a list of attributes is much better.
We use something suitable as our menu resource, but folks have argued
for XML too.  I don't want to bring in something as heavy and complex
as XML, but maybe a small parser like our resource parser that just
happened to use XML format would buy us some usefulness at low cost.

For performance reasons, it might be useful to have both an ASCII and
a compiled binary format for these, with a converter.  I've done stuff
like this before; parsing a huge ascii file is a CPU hog compared to
something designed to be digested by a program.

Note we already have the ability to store attributes at the layout,
layer, and element level.  Perhaps that would be one place to hold new
DRC rules?  If we tagged the rulesets, we could then assign those tags
to objects on the board, although storing such tags means a file
format change.  Maybe the new format can specify mandatory stuff as
the first few non-tagged values (like line start/end coordinates) and
have everything else be tagged after that (like clearance=1mm) so it's
more free-form?  We'd need some meta-rules for specifying defaults.

Re: DRC

Our DRC engine could use a complete rewrite.  It doesn't get arcs
right, for example.  It would be nice if it told us the *actual*
design rules used (what's the closest cross-net spacing?  Smallest
drill?  Etc) too.

Re: recursive PCBs

I think the first step in this type of change is to tag layers by
type.  I've spec'd this out before, I think, and it's the Upgrade of
layer and design objects in our big statement of work (SOW):

http://www.geda.seul.org/wiki/geda:pcb_funding_sow

Those items are approximately in do-in-this-order order, but the GUI
stuff can go anywhere.  Anyway, layer design tags each layer with a
type, such as top side silk or inner keepout (a combination of a
where and a what, and optional invert).

This is the basis for elements-as-pcbs and nested pcbs.  The tricky
part is not the data structures, but mapping the various layers in
each submodule.  For example, if you imported a two-layer board module
into a four-layer board, what happens?  Or an element description with
keepaway on all inner layers, how does that map to a six-layer
board?  Etc.

Some of that work can be made easier to code if we switch to C++
officially so we can use a real OO language instead of the OO hack we
currently have.  There's a patch in the tracker to make the code
C++-compatible, someone (i.e. me) needs to review it so we can get it
committed and start seeing who'll have problems if we switch to C++.

Then you could have each object know how to draw itself (or part of
itself, usually by layers) just by foo-draw().  I don't think this is
*needed* though.  We just need a new object type that is itself a PCB
(or at least the PCB-Data structure, like a Buffer), a way to nest
all the draw/find/select etc stuff, and a way to tell the GUI which
object(s) you're editing.  That automatically gives you a footprint
editor too :-)

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.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user




___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread Andrew Poelstra

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 format,
 but seeing clearance=5mil in a list of attributes is much better.
 We use something suitable as our menu resource, but folks have argued
 for XML too.  I don't want to bring in something as heavy and complex
 as XML, but maybe a small parser like our resource parser that just
 happened to use XML format would buy us some usefulness at low cost.


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.

Plus, it would make it very easy to manipulate PCBs in Lisp, which is
a far nicer language to work with than Perl, which AFAICT is the most
common language for gEDA hacking.
 
 For performance reasons, it might be useful to have both an ASCII and
 a compiled binary format for these, with a converter.  I've done stuff
 like this before; parsing a huge ascii file is a CPU hog compared to
 something designed to be digested by a program.
 
 Note we already have the ability to store attributes at the layout,
 layer, and element level.  Perhaps that would be one place to hold new
 DRC rules?  If we tagged the rulesets, we could then assign those tags
 to objects on the board, although storing such tags means a file
 format change.  Maybe the new format can specify mandatory stuff as
 the first few non-tagged values (like line start/end coordinates) and
 have everything else be tagged after that (like clearance=1mm) so it's
 more free-form?  We'd need some meta-rules for specifying defaults.


I made another post to this list wherein I suggested structuring DRC rules
as objects in their own right: consisting of a filter (what it affects) and
a rule (what it requires).

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.

 
 Re: DRC
 
 Our DRC engine could use a complete rewrite.  It doesn't get arcs
 right, for example.  It would be nice if it told us the *actual*
 design rules used (what's the closest cross-net spacing?  Smallest
 drill?  Etc) too.
 

Speed might be a problem, but again, Lisp would be a huge boon to this,
if only because of the immense amount of AI-related stuff out there.


 ...
 
 Some of that work can be made easier to code if we switch to C++
 officially so we can use a real OO language instead of the OO hack we
 currently have.  There's a patch in the tracker to make the code
 C++-compatible, someone (i.e. me) needs to review it so we can get it
 committed and start seeing who'll have problems if we switch to C++.


C++ would be a definite improvement. However, it's a scary-huge language
and I'm not sure the pros would outweigh the cons. (Of course, it's a far
easier port than any other language would be.)

There aren't a lot of other compiled languages to consider, though, that
would do what we want with the speed that we need. What is the opinion of
D in this group?
 
 Then you could have each object know how to draw itself (or part of
 itself, usually by layers) just by foo-draw().  I don't think this is
 *needed* though.  We just need a new object type that is itself a PCB
 (or at least the PCB-Data structure, like a Buffer), a way to nest
 all the draw/find/select etc stuff, and a way to tell the GUI which
 object(s) you're editing.  That automatically gives you a footprint
 editor too :-)
 

Agreed, but given the pain it would take to create a workable PCB object,
I think we'd be better off just going to a real OO language.

 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.
 

I really don't want to do GUI work, but I'm finding it's necessary to
developing functional blocks. Mainly because without GUI support, having
functional blocks is nearly useless.

And in the process, I'm learning Gtk and GUI development in general. And
learning is always a good thing :). For now, modernizing the entire GUI
is well beyond my abilities.


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread Andrew Poelstra

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
generally ugly.

Plus, the entire spec is enormous, and using only a subset of the spec
means that we've lost a lot of the compatibility arguments in favor of
it.


Andrew
 


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread Andrew Poelstra

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 it's
a huge complicated mess, both for the user and in the code.


For layer mappings, things don't necessarily have to be difficult. Especially
if we had a good file format, people could write their own scripts if they
want to do crazy things.

In the meantime, we could:


1. Refuse to export-as-footprints any PCB with more than one copper layer.
   This will likely eliminate the most common problems.

2. As for PCB components that are themselves PCBs (ie, recursive PCBs), we
   could present the user with a mapping dialog when he tries to import a
   sub-PCB.


The dialog would look something like (when importing a 6-layer sub-PCB
into a 5-layer PCB):


  Imported PCB   Current PCB
Silk   -- Silk
Top-- Top
Layer One  -- Layer One
Layer Two  -- Layer Two
Layer Three-- Bottom
Bottom -- *New Layer...*


The left-hand column is read-only. The right-hand column consists of
drop-down boxes listing all the existing layers. Selecting *New Layer...*
would pop up the New Layer dialog.

We could even store this mapping information in the .pcb file and allow
the user to change it after-the-fact.


Andrew



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes

2010-09-03 Thread timecop

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 gnuarm.2...@arius.com wrote:
 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 machines, difficult to parse and
 generally ugly.

 Plus, the entire spec is enormous, and using only a subset of the spec
 means that we've lost a lot of the compatibility arguments in favor of
 it.


 Andrew

 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, mechanical, etc, even board lay up.  So the compatibility
 issue is moot because any one app only needs to deal with the portion that
 applies to it.  Just don't muck with the other parts.

 The heavy issue is a red herring (are you planning on hosting this on a
 cell phone maybe?)  No PCB file format is going to be easy for humans to
 read.  Bandwidth?  Back to the MCU in the cell phone I guess.  Ugly, now
 there is a great technical argument.

 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?

 Rick


 ___
 geda-user mailing list
 geda-user@moria.seul.org
 http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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'd get synthetic tags like line-rule or
pin-rule.

 Speed might be a problem, but again, Lisp would be a huge boon to this,
 if only because of the immense amount of AI-related stuff out there.

gschem uses a lot of lisp (in the guise of Guile).  No thanks.
Despite PCBs being object oriented, they're not *data* oriented like
Lisp is.

 C++ would be a definite improvement. However, it's a scary-huge language

No, it's not.  It has much more *capability* than C but you don't
*have* to use it all.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Functional blocks and PCB format changes


 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/geda-user

Re: gEDA-user: Functional blocks and PCB format changes