Re: gEDA-user: Driving the netlist from PCB (instead of gschem)

[Rick Collins <erudite999@xxxxxxxxx>]

At 11:31 PM 9/29/2008, you wrote:

> > > > If you just update the schematic and import the new net list,
> > > > doesn't that cause the trace for that net to be ripped up?
> > >
> > >It doesn't rip it up, but it does show up as a short.
> >
> > And how is that then fixed?
>
>It's not fixed.  You still have to edit the board to make it match the
>netlist; my process just makes sure that the board editing is always
>working *towards* matching the schematic, not *away* from it.

I don't think you understood my question.  The answer is that it is 
fixed by the user manually fixing it.

I don't think the "direction" of the changes is especially 
important.  If you have to go into the schematic before you can think 
about a change, I don't think this is the best way.  Maybe I don't 
know what is involved in "fixing" a short, but it sounds like it is 
ambiguous.  As long as it is clear what needs to be ripped up, then 
that works.


> > >Support in the applications for data and syntax they won't be using.
> >
> > I don't follow.  The "syntax support" is just to ignore the entire
> > section that does not apply to schematic or whatever part is being
> > considered.  That doesn't strike me as a lot of overhead.
>
>You still have to find the end of it, unless you use a syntax that can
>be parsed without understanding the content.  And you have to remember
>it, so you can write out an updated file later.  If the file only
>contains data you care about, you don't have to remember all the extra
>data.

I don't agree that you have to "remember" all of the unrelated 
stuff.  The file can be read and unrelated text can be passed through 
while the relevant text is replaced.  The entire file does not have 
to be read into a structure in the program.


> > >We've discussed XML before, and chose not to use it due to the uneeded
> > >complexity.  Some other structured text format may be used though.
> >
> > What "uneeded complexity"?
>
>The XML parsing libraries are huge and have dependencies, in order to
>support the large degree of flexibility that XML offers.  We don't
>need all that.  It's overkill for us, esp since we already have an
>xml-like parser that's much simpler and very small.
>
> > The idea that the internal and external format could be the same
> > seems much simpler than to store in one format and then have to
> > convert to the other... of course this is assuming that the IPC
> > standard becomes adopted by industry.
>
>The "internal format" is going to be a binary data structure that's
>machine dependent.  We can't just "store" that on disk.

By "internal" I am referring to the file used by the layout 
program.  I am not concerned about data structures internal to the 
program.  I mean internal in the sense of not being output such as 
CAM files.  Although the advantage is that the an IPC XML standard 
file can do both.


> > But there is a huge advantage to being "standard".
>
>I agree, but if we can support a subset of the "standard" as an
>exporter, and still have a native format that works best for us,
>that's good enough.

That is not at all what I am talking about.  That is what exists now, 
a unique format for the layout file of each layout program and a 
common format to export to manufacturing tools... or actually *many* 
common formats, some of which are not even standard.  That was how I 
got into this in the first place.  I found the hard way that there 
are no standards (currently) for the XYRS centroid data file among others.


> > Often people optimize things that are not really needed because that
> > is what they do.
>
>I'm not considering "optimizing" the file format.  I'd rather design
>something less optimal but more flexible and future-proof.  More of
>the design choices are about the data stored and its structure, not
>the format.  Part of that relates to the internal data structure,
>which was designed a few decades ago.  Changing that takes a lot of
>time and thought.

Yes, that is what I am referring to.  It makes sense to use a file 
format that is not so unique to each individual layout program.  But 
so far everyone seems to have made their own.  



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