X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=6S43UDOw369V2411EJ7UTFtuHLYsH1ovbiXt2zFYjlI=; b=08lLjvQuzWcnweEOFN2epOZyMmjZVJ/zlKn8tB/aPyg9x1jiMEJVknlhf566XsbxM4 1j8CQs9Y2n6lh7iPxVg+Fe84+kCJvkxwAb37FDdsCqyrUCkAjp4hfoTwog4rt07ESSDv RmTIpWSDHkevcCzo+CaP77HoFkfJxny1s4qmjAke856hs44du1w7yiYATzIMCkmOkwJI MogmtloObeCkPhtYQq0d0cIWHygeXfVnfiOClncNOm6WtKpVibxWk8s8uCNAufFwK3D5 7XVB6TemVdn0sqOfxsMnyA/LZKemaujs7zkzsqIF8wM3qkrGrWAp7kqWBTNFs5U/ITyO ZGGg== MIME-Version: 1.0 X-Received: by 10.112.161.197 with SMTP id xu5mr40267421lbb.69.1436016305859; Sat, 04 Jul 2015 06:25:05 -0700 (PDT) In-Reply-To: References: Date: Sat, 4 Jul 2015 13:25:05 +0000 Message-ID: Subject: Re: [geda-user] libgeda3 From: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" To: geda-user AT delorie DOT com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id t64DPCq2026415 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 Roland, No offense but I am trying to add onto what already exists. gEDA already suffers from too much fragmentation of effort. On Sat, Jul 4, 2015 at 12:19 PM, Roland Lutz wrote: > 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 -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/