On Aug 9, 2009, at 12:45 PM, Peter TB Brett wrote: > On Sun, 9 Aug 2009 12:09:01 -0600, John Doty <[email protected]> wrote: > >> With the exception of the flow from gschem to layout in another >> suite, which works radically well. How to generalize? Well, if you >> want to export schematics instead of just netlists and BOM's, a >> gnetlist back end needs access to all the schematic data, not just a >> subset. The barrier here is all of the unnecessarily hard-wired >> behavior in the gnetlist front end. > > One project I've had in mind for a while is to write a "geda-netlist" > program in (almost) pure Scheme,
Would you parse the schems/symbols with libgeda? > which when run as "gnetlist" behaves the > same as the current C gnetlist, but when run as "geda-netlist" Not clear to me that you need that. Backends that limit themselves to the old API could get the old behavior. > uses new > backends which have a lot more access to the netlist internals in > order to > get full control over the way that the schematics and symbols are > processed. The longer I think about this, the more useful applications I see. > > This is one of those things that I will do "Soon" (tm). If you want help... > > Peter ;-) > > -- > Peter Brett <[email protected]> > Remote Sensing Research Group > Surrey Space Centre > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
