X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sat, 4 Jul 2015 14:19:32 +0200 (CEST) From: Roland Lutz To: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" Subject: Re: [geda-user] libgeda3 In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-2024431822-1436012372=:8210" 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-2024431822-1436012372=:8210 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 4 Jul 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote: > Is anyone working on it? I'm working on it, though I'm not calling my effort "libgeda3". When you compare the intentions behind Xorn with the "Rationale" section from http://wiki.geda-project.org/libgeda3 , this becomes obvious: > The current version (2.x) of the libgeda shared library has a number of > defects: > > - Poor separation between public interface and internals, which leads > to… > - Frequent changes to the API > - API contains large amounts of code specific to application internals > > This page is an attempt to itemise in detail what is required of > libgeda, and what the interface to it should look like. This will > enable: > > - More rigorous testing of library functions > - Creation of language bindings for libgeda > - Easier development of other applications for manipulating schematics The main difference between the libgeda3 and Xorn philosophies is that I'm not trying to provide an API but a Python ecosystem in which different parts of the code (e.g. upstream Xorn/gEDA and user code) interact natively. All code is "part of" the ecosystem in some way, regardless of whether the user has invoked it using one of the existing command-line programs or it has been included by another application. In detail: > Requirements > Core > - Define data structures for representing schematics > - Provide methods for creating and manipulating schematics These are the xornsch_* structs and xorn_* functions defined in xornstorage.h, or the classes and methods defined in he module xorn.storage for Python. > - Provide methods for reading and storing schematics into files and > data streams This is implemented in the modules xorn.geda.read and xorn.geda.write. > - Provide access to detailed data on errors and exceptions This is planned, but I didn't have time to implement it yet. > - Provide a simple interface for configuring libgeda's behaviour I'm trying to avoid this. Changing the core behavior of libgeda and gnetlist to achieve different behavior has been a main source of problems for me when working with the codebase. I'm trying to make the standard behavior more flexible instead so changing the code's behavior isn't necessary any more. > Secondary > - Make no assumptions about applications which will use the library Check. > - Make no assumptions about the compiler or architecture on which the > library is being used (Check), I've not really tested this yet and expect there to be some minor problems. > - Fully reentrant for thread safety Threads aren't really supported. This is a substantial problem and IMHO the only real downside to using Python. It's similar, though, for most other high-level languages. > - Minimise number of dependency libraries Python is obviously required, as well as the usual build system toolchain. Apart from that, check. > - Detect and gracefully handle multiple instances accessing the same > schematic file Big check. :-) I think Xorn is the way to go for future gEDA development. Once I've cleaned up the pythonized version of gnetlist, it could be included in upstream gEDA, leaving gschem as the primary remaining user of libgeda. Porting the smaller tools to Xorn shouldn't be a problem. Then libgeda, with all its gschem-specific functionality, could be made a part of gschem again. By having it use the Xorn primitives, code duplication could be reduced, and gschem could be integrated with the rest of gEDA on a schematic-manipulation basis. Roland --8323329-2024431822-1436012372=:8210--