Re: gEDA-user: Functional blocks and PCB format changes
Kai-Martin Knaak wrote: Andrew Poelstra wrote: The problem I have with JSON (and to some extent, Lisp) is that it is not self-documenting. You can't open a JSON document and immediately see what everything is and what it does; it just looks like gibberish and brackets. +1 Whatever 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. emote_mode_please_skip_if_offended Because of progress in hardware, I can lift terrabytes easily. To all, that think what_not_pointless_name_which_is_very_verboseC5\what_not_pointless_name_which_is_very_verbose is friendly to humans, I wish they have to wade through this up to their nose for ages. Who needs whitespace? I mean, if the parser can do without it, why waste some thought on pretty printing. MS don't pay their OSS compatibiltiy guys for that. I've been programming HTML for years - it's ok, but not my favourite choice. +1 to JSON or YAML ;-) and a very concise choice of names. We don't have extremely complicated structures, so 3 brackets are managable. \emote_mode_please_skip_if_offended Would this have been comprehensible as: { emote_mode_please_skip_if_offended: Because of progress in hardware,... } ? At least it's machine-convertible to XML. Does XML have a notion of orderd lists? ___ 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
DJ Delorie wrote: Perhaps we store the internal data in a structure that can be exported/imported in *any* structured format, and let those who really want format XYZ to add the import/export logic for it? +=3, just repeat my self twice ;-) ___ 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
Steven Michalske wrote: We had that: M4 footprints. I never liked those, I could not figure out how to use them. But I love them! I love them too! I don't ;-) I keep mine up to date, so I don't use a - (dash) in foot print names, its a price I am willing to pay. It is a price everyone has to pay one way or another. Yes, you can get away with hyphenated footprint names if you explicitly tell gsch2pcb not to use M4. But mishap will may still strike if you share your shiny library with other users. ---)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
Has anyone looked into what it would take to properly quote footprint names, so that hyphens *can* be used in them without m4 issues? I mean, we don't have to support *m4* footprints with hyphens, but at least get past that to find newlib names? ___ 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
Hi Rick, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Rick Collins Sent: Friday, September 17, 2010 4:05 PM To: gEDA user mailing list Subject: Re: gEDA-user: Functional blocks and PCB format changes I've actually given this some thought. On one hand it seems like a footprint file language might seem like a good idea. But there is a lot to consider. What is the real advantage over the scripts you currently use to generate a fixed format footprint file? What is the advantage over a footprint generator? One of the clear disadvantages of a footprint language is the difficulty in verifying that you have correctly drawn the footprint. You would need a tool for that which would look a lot like a footprint generator. It can also be problematic dealing with bugs when the language gets used in the corner cases or unusual ways. FreePCB has a pretty versatile footprint generator that deals with all the standard sorts of features in the standard footprints. It is capable of understanding the files it generates so that it can be used to edit these footprints as well. If you have an odd part that has some regular features and also odd features, it can accommodate that too. I have never needed to hand edit a footprint file when using this tool. Best of all, it is GUI and interactive so I can see exactly what I am doing. A footprint language may be quick for some things, but I think a GUI footprint editor with a standard, non-programmable file format is a much better general tool. Rick For a pcb FootPrint Wizard have a look at: http://github.com/bert/pcb-fpw For the sources (git). A manual with screenshots can be found at: http://www.xs4all.nl/~ljh4timm/pcb-fpw/user-manual.html I'm still debugging, so consider this a work in progress. Changing the pcb footprint file format will not speed up a new release. 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
Phil Frost: ... XML and YAML are equally capable of being made unreadable. Either can be made more readable by defining a reasonable schema and selecting a clueful output library. Neither sed nor awk can process XML or YAML the right way in all cases without reimplementing a libyaml or libxml in sed or awk. Ack, one can make an file format unreadable, and one can make it reasonably readable. But that is only one side of the problem. I am also conserned with how easy it is to write it (e.g. footprint files). Currently I'm trying to learn to make footprint files (since I need them). And it seems that I almost always end up making a script making the needed files. For me, it means that the file format is not expressive enough. *** I would like the file format to be programmable, at least at the footprint level. 1, A first step could be to allow variables in the files, e.g. to be able to write: pad_dims = 1.1mm 0.5mm 1.300mm Pad [ -1.700mm -0.300mm -1.700mm 0.300mm $pad_dims 1 1 square] Pad [ 1.700mm -0.300mm1.700mm 0.300mm $pad_dims 1 1 square] or x = 1.7mm y = 0.3mm pad_dims = 1.1mm 0.5mm 1.300mm Pad [ -$x -$y -$x $y $pad_dims 1 1 square] Pad [ $x -$y$x $y $pad_dims 1 1 square] or pw = 1.1mm # pad width ph = 1.7mm # pad height pd = 2.3mm # pad distance x = $pd/2 + $pw/2 y = $ph/2 ... 2, Next step could be to allow subroutines in the native format, eg.: two_pads(pad_width, pad_heigth, pad_separation, component_width) { ... } 1206_reflow_soldered = two_pads( 0.9mm, 1.7mm, 2.0mm, 1.6mm ) 1206_wave_soldered = two_pads( 1.1mm, 1.7mm, 2.3mm, 1.6mm ) clearance = 0.5mm soler_mask_clearance = 0.3mm 1206_my_version = ... or (if you don't like positional parameters): 1206_wave = two_pads( pw=1.1mm, ph=1.7mm, pd=2.3mm, cw=1.6mm ) instead of file 1206_wave.fp: # Vishay D../CRCW e3 # http://www1.elfa.se/data1/wwwroot/assets/datasheets/flD-CRCW-e3_data_en.pdf Element [ 0 0 -0.7mm -0.8mm 0 100 ] ( Pad [ -1.700mm -0.300mm -1.700mm 0.300mm 1.1mm 0.5mm 1.300mm 1 1 square] Pad [ 1.700mm -0.300mm1.700mm 0.300mm 1.1mm 0.5mm 1.300mm 2 2 square] ElementLine [ -2.510mm 1.110mm2.510mm 1.110mm 0.32mm ] ElementLine [ 2.510mm 1.110mm2.510mm -1.110mm 0.32mm ] ElementLine [ 2.510mm -1.110mm -2.510mm -1.110mm 0.32mm ] ElementLine [ -2.510mm -1.110mm -2.510mm 1.110mm 0.32mm ] ) file 1206_reflow.fp: etc 3, another possibility would be to use postscript or some other language as the file format. /mm 72 25.4 div def mm mm scale 0.1 setlinewidth /pw 1.1 def /ph 1.7 def /pd 2.3 def /x pd 2 div pw 2 div add def /y ph 2 div def ... *** Would patches for something like this be accepted? Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ 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
k...@aspodata.se (Karl Hammar) writes: I would like the file format to be programmable, at least at the footprint level. We had that: M4 footprints. I never liked those, I could not figure out how to use them. But if you drop the parameters, and make a non-parameterized top-level file for each footprint, so that ls(1) tells me what footprints are available, I might like it. -- Stephan ___ 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've actually given this some thought. On one hand it seems like a footprint file language might seem like a good idea. But there is a lot to consider. What is the real advantage over the scripts you currently use to generate a fixed format footprint file? What is the advantage over a footprint generator? One of the clear disadvantages of a footprint language is the difficulty in verifying that you have correctly drawn the footprint. You would need a tool for that which would look a lot like a footprint generator. It can also be problematic dealing with bugs when the language gets used in the corner cases or unusual ways. FreePCB has a pretty versatile footprint generator that deals with all the standard sorts of features in the standard footprints. It is capable of understanding the files it generates so that it can be used to edit these footprints as well. If you have an odd part that has some regular features and also odd features, it can accommodate that too. I have never needed to hand edit a footprint file when using this tool. Best of all, it is GUI and interactive so I can see exactly what I am doing. A footprint language may be quick for some things, but I think a GUI footprint editor with a standard, non-programmable file format is a much better general tool. Rick At 04:55 AM 9/17/2010, you wrote: Phil Frost: ... XML and YAML are equally capable of being made unreadable. Either can be made more readable by defining a reasonable schema and selecting a clueful output library. Neither sed nor awk can process XML or YAML the right way in all cases without reimplementing a libyaml or libxml in sed or awk. Ack, one can make an file format unreadable, and one can make it reasonably readable. But that is only one side of the problem. I am also conserned with how easy it is to write it (e.g. footprint files). Currently I'm trying to learn to make footprint files (since I need them). And it seems that I almost always end up making a script making the needed files. For me, it means that the file format is not expressive enough. *** I would like the file format to be programmable, at least at the footprint level. 1, A first step could be to allow variables in the files, e.g. to be able to write: pad_dims = 1.1mm 0.5mm 1.300mm Pad [ -1.700mm -0.300mm -1.700mm 0.300mm $pad_dims 1 1 square] Pad [ 1.700mm -0.300mm1.700mm 0.300mm $pad_dims 1 1 square] or x = 1.7mm y = 0.3mm pad_dims = 1.1mm 0.5mm 1.300mm Pad [ -$x -$y -$x $y $pad_dims 1 1 square] Pad [ $x -$y$x $y $pad_dims 1 1 square] or pw = 1.1mm # pad width ph = 1.7mm # pad height pd = 2.3mm # pad distance x = $pd/2 + $pw/2 y = $ph/2 ... 2, Next step could be to allow subroutines in the native format, eg.: two_pads(pad_width, pad_heigth, pad_separation, component_width) { ... } 1206_reflow_soldered = two_pads( 0.9mm, 1.7mm, 2.0mm, 1.6mm ) 1206_wave_soldered = two_pads( 1.1mm, 1.7mm, 2.3mm, 1.6mm ) clearance = 0.5mm soler_mask_clearance = 0.3mm 1206_my_version = ... or (if you don't like positional parameters): 1206_wave = two_pads( pw=1.1mm, ph=1.7mm, pd=2.3mm, cw=1.6mm ) instead of file 1206_wave.fp: # Vishay D../CRCW e3 # http://www1.elfa.se/data1/wwwroot/assets/datasheets/flD-CRCW-e3_data_en.pdf Element [ 0 0 -0.7mm -0.8mm 0 100 ] ( Pad [ -1.700mm -0.300mm -1.700mm 0.300mm 1.1mm 0.5mm 1.300mm 1 1 square] Pad [ 1.700mm -0.300mm1.700mm 0.300mm 1.1mm 0.5mm 1.300mm 2 2 square] ElementLine [ -2.510mm 1.110mm2.510mm 1.110mm 0.32mm ] ElementLine [ 2.510mm 1.110mm2.510mm -1.110mm 0.32mm ] ElementLine [ 2.510mm -1.110mm -2.510mm -1.110mm 0.32mm ] ElementLine [ -2.510mm -1.110mm -2.510mm 1.110mm 0.32mm ] ) file 1206_reflow.fp: etc 3, another possibility would be to use postscript or some other language as the file format. /mm 72 25.4 div def mm mm scale 0.1 setlinewidth /pw 1.1 def /ph 1.7 def /pd 2.3 def /x pd 2 div pw 2 div add def /y ph 2 div def ... *** Would patches for something like this be accepted? Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ 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
Stephan Boettcher boettc...@physik.uni-kiel.de wrote: We had that: M4 footprints. I never liked those, I could not figure out how to use them. But I love them! MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Functional blocks and PCB format changes
On Sep 17, 2010, at 9:17 AM, Michael Sokolov wrote: Stephan Boettcher boettc...@physik.uni-kiel.de wrote: We had that: M4 footprints. I never liked those, I could not figure out how to use them. But I love them! I love them too! I keep mine up to date, so I don't use a - (dash) in foot print names, its a price I am willing to pay. MS ___ 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 prefer: # -*- makefile -*- CSA-L%.sch: CSA-1.sch Makefile sed 's,^\(refdes\|netname\)=,L$*_,' $ $@ CSA-N%.sch: CSA-2.sch Makefile sed 's,^\(refdes\|netname\)=,N$*_,' $ $@ FSH-S%.sch: FSH-1.sch Makefile sed 's,^\(refdes\|netname\)=,S$*_,' $ $@ direna-preamp-P%.sch: direna-preamp-1.sch sed 's,^\(refdes\|netname\)=,P$*_,' $ $@ TFlex-34.pcb: TFlex.pcb Makefile sed $ $@ '/^Element.*\(c1206\|c0805\|c0603\|CWR11B\)/,/^..$$/d;/^Via.* 400 .$$/d;/Groups/s/1,c:2,3:4:5:6,7:8,s/1:2,3:4,c:5,s:6,7:8/' TFlex-16.pcb: TFlex.pcb Makefile sed $ $@ '/^Element.*Omne/,/^..$$/d;/^Via.* 400 .$$/d' -- Stephan ___ 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
Steven Michalske smichal...@gmail.com writes: Now we may want to write a parser, and emitter, but that is a good amount of work, to serialize a data structure in the code that could be output be a data serializer that just works. The emitter shall conserve order and formatting (probably not) or at least be deterministic about it, so that load-save cycles do not screw with the subversion/git/... diffs. -- Stephan ___ 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 09/13/2010 09:57 PM, Ouabache Designworks wrote: pin: pinNumber: 2 pinName: rst x1: 1234 y1: 4321 x2: 2345 y2: 4321 layer: component or pinpinNumber2/pinNumberpinNamerst\pinNamex11234\x1y 14321\y1x22345\x2y25432\y2layercomponent\layer\pin I call the second large, bloat, and ugly. I would prefer rectangle: type: pin pinNumber: 2 pinName: rst x1: 1234 y2: 4321 x2: 2345 y2: 4321 layer: component or rectangle, ID = 92135 typepin pinNumber 2\pinNumber pinName rstpinName \type basepos ref92134\basepos loc, ID = 12359 x 1234\x y 4321\y \loc, ID = 12360 loc, type = rel x \x y 0\y \loc \rectangle I'm not exactly sure how the referenced position will work out in XML or the first format (yaml?). Time for me to leave the house - so I'm not sure how correct any of this is. ___ 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 04:25:49PM -0700, Steven Michalske wrote: 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 would point out a valid YAML representation of the above is also: {pin: {pinNumber: 2, pinName: rst, x1: 1234, y1: 4321, x2: 2345, y2: 4321, layer: component}} and also: {pin: {pinNumber: 2, pinName: rst, x1: 1234, y1\ : 4321, x2: 2345, y2: 4321, layer: compo\ nent}} A valid XML representation, using a slightly different schema, is: pin pinNumber='2' pinName='rst' x1='1234' y1='4321' x2='2345' y2='5432' layer='component' / XML and YAML are equally capable of being made unreadable. Either can be made more readable by defining a reasonable schema and selecting a clueful output library. Neither sed nor awk can process XML or YAML the right way in all cases without reimplementing a libyaml or libxml in sed or awk. ___ 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
Phil Frost ind...@bitglue.com writes: I would point out a valid YAML representation of the above is also: {pin: {pinNumber: 2, pinName: rst, x1: 1234, y1: 4321, x2: 2345, y2: 4321, layer: component}} Neither sed nor awk can process XML or YAML the right way in all cases without reimplementing a libyaml or libxml in sed or awk. This one-line form is pretty accessible to sed and awk. I'd write an awk script that transforms arbitrary YAML into this form, and include that in any commandline pipe of one-liner processing. At the next save from PCB it will be back to the original format, so that subversion diff will happy. I like that format. -- Stephan ___ 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: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/ Recently I had to implement multiple output formats for a project of mine, including xml, JSON and plist (property list). After that session, for simple trees, I'd prefer plist over JSON. Myabe it's just me but i found it more readable for the human eye (independent of the indentation). 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
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. That isn't to say that JSON is right every where, but I think it is more frequently the correct choice than XML is. ___ 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: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
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
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
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
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
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
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
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
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 ___ 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
-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
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
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
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
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
gEDA-user: Functional blocks and PCB format changes
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
Re: gEDA-user: Functional blocks and PCB format changes
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
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
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
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
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
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
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
The heavy issue is a red herring The heavy issue impacts the difficulty in using XML as a toolkit. But I suppose it is better to re-invent the wheel. There is no reason to try to foster any sort of compatibility in file formats between all the different CAD tools. That's a real red herring, since nearly all non-free cad tools use proprietary binary formats anyway. There's nothing to be compatible *with*. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user