X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sat, 12 Sep 2015 11:52:09 +0200 (CEST) From: Roland Lutz To: geda-user AT delorie DOT com Subject: Re: [geda-user] About reinventing the wheel, and how to avoid it In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-873903576-1442051215=:2663" Content-ID: Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-873903576-1442051215=:2663 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 11 Sep 2015, John Doty wrote: > On Sep 11, 2015, at 8:06 AM, Roland Lutz wrote: >> 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? Hm. Maybe you got a point here. It's actually quite hard to describe what a library is for when you're waist-deep in its internals. Let me try to explain it a different way: libxornstorage is a C library that defines structs for all necessary object types (currently schmatic objects), and manages lists of these structs. By imposing a strict data model on the using application (no additional fields in the structs, no update triggers, etc.), it makes sure no application has its own special exceptions on the data model. This allows a C application (gschem), a Python application (xorn netlist), and possibly user scripts in arbitrary languages to access the same in-memory data without having to worry about the other code's implementation details. Additionally, it allows applications to use a "value-oriented" approach to file states. This means you can either create one empty "file revision" and change it as you wish, or you can "finalize" a revision (make it read-only) and force others to create a copy if they want to change it. (This copy should obviously be implemented in an efficient way.) For example, if a user script is called as an action from gschem, the state before the invocation could be a finalized revision, and the state the script changes could be a copy of that. After the script finishes, gschem would use xorn_get_modified_objects etc. to update its display and associate the previous revision with the last undo step. >> 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. That's because xorn-netlist lacks Scheme support, and, admittedly, I probably won't add it any time soon. Apart from that, it is pretty much the same code (or rather was, before I started refactoring it) and should produce identical output (except for a few well-documented differences). >> 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. That would defeat the whole purpose of libxornstorage. Think of it not so much as of a traditional library as of a refactoring help. It does provide some functionality (or rather allows its implementation to do so), but that's not the point. The library interface is designed in such a way that, by moving to use libxornstorage, a project is forced to adapt an internal architecture that allows the kind of intra-process communication which I outline above. This is only an implmentation detail; it doesn't affect Scheme or Python or other user-visible things in any way, and it is also the only kind of integration which I intend to do in the relatively near future (so calm down, please :). On the long term, I'd like to move the functionality that would be handy to have in a library out of libgeda (which itself isn't in practice usable for inclusion in other programs) into a new library. Since much of the functionality of libgeda is high-level and rather cumbersome to implement in C, I chose Python for that task. This doesn't mean all programs using that library have to be written in Python any more than that fact that libxornstorage is written in C means that programs using it would have to be written in C. In fact, I've already started to write a back-binding library which allows using xorn.geda from pure C code. >> The obvious thing would be to continue that scheme for PCB, too > > The big difficulty I see here is that geda-gaf is a bottom-up design: > […] Geda-pcb, by contrast, is top-down with restricted goals and > capabilities. […] 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. Maybe extracting the functionality that would be handy to have in a library is harder from PCB than it is from libgeda, but I don't see any fundamental problems here. As Nicklas already suggested, pulling out the file reading/writing code into a library is probably one of the first steps (though I'd put adapting and using libxornstorage first, considering the state of the code base, as this may avoid many shudderings later). Roland --8323329-873903576-1442051215=:2663--