Mail Archives: geda-user/2015/09/11/11:52:44
Roland,
Let me reiterate that I’m very impressed with what you’re doing. Please do not let my modest dissent from some of the things you’re saying discourage you from this excellent work.
On Sep 11, 2015, at 8:06 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
> While reading the past discussions here on the list, I had the impression that some ideas are developed over and over again, while few people took notice of the infrastructure which I already created.
>
> An in-memory database? Look at libxornstorage.
I have, and it’s hard to comprehend given the state of the documentation. The first time I looked at it, I saw Yet Another OO Framework. What’s this for? Your productivity with xorn is very, very impressive, but I confess that I don’t “get” it at all.
> An interchange mechanism between programs written in different languages? Look at libxornstorage and write a wrapper for your favorite language if it doesn't already exist.
>
> I'm not "working on the Python branch", and I haven't "created a complete parallel to gnetlist, but based on Python rather than Scheme". xorn-netlist *is* gnetlist.
Not really. I don’t see xorn-netlist replacing gnetlist in projects that already use custom Scheme scripts. And, at this point, I’m not sure I will want to switch for things that gnetlist does well.
> I'm gradually shifting the gEDA infrastructure to a more modular design, using C where I have to (for interoperability with any language) and Python where I can (for those implementation parts which don't have to be hand-optimized in C). In the process, I converted the API for netlist backends to Python, but that was partly because there are no Guile bindings in Python, and the code turned out to be much easier this way.
>
>
Please continue with xorn as a parallel effort, as you’ve so far done with success. Some of us have too much investment in the old geda-gaf to switch easily.
> The obvious thing would be to continue that scheme for PCB, too:
>
> xorn.storage - in-memory representation of PCB objects
> xorn.pcb.read - reads .pcb files
> xorn.pcb.write - writes .pcb files
> xorn.pcb.netlist - creates netlists for back annotation
> xorn.pcb.render - renders PCBs to Cairo for display and PDF export
The big difficulty I see here is that geda-gaf is a bottom-up design: the .sch format provides a simple, general description of networked objects in a hierarchy with metatadata in the form of attributes. Then, we add symbol libraries and scripts to adapt this to specific applications. Xorn obviously works well with this, and gives me great hope for the future. To me, the real barrier to completely exploiting geda-gaf’s flexibility has been the clumsiness of the Guile<->C FFI.
Geda-pcb, by contrast, is top-down with restricted goals and capabilities. Where geda-gaf describes topology in a general way that has few restrictions, geda-pcb has no general basis in geometry. Where geda-gaf uses attributes in mostly unrestricted ways, geda-pcb *enumerates* a restricted subset of possibilities. Adding a small subset of possible layer types to this approach has been cheered as a great advance here. Sorry, Nicklas, it makes me shudder. I expect that a xorn-pcb would be as frustrating. Unlike geda-gaf, where the frustrations have been rooted in the implementation, the frustrations of geda-pcb are rooted in the design.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -