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=PRcrm9Qvwb39IcVurFYSzyOty1D46O/gGy2CD5gnEm0=; b=C8D6FvJu4UP0Ylv//uf5/8h9bsW77wn5/8KzCnpP1CRLRFLjLAADhaXEsAkCrhlEXN RQiBK/les32KK6Zi2KHyeE4ExNaSU9FnnHop5306H0OFMy8CV5GXj3NzcZKzxRzqxyGT uAKXE/UFCrK91O6Efa/u6LOj+YUqTC9POR+uHvqQvPrU7EoTO4wQnXVvQ4tmyPEJDwQv N04ixYCtuM0/raEkPnHvF1TzuFT4DjD89KtcFI4jdfOnPr/Ix9Ti6teyOAh3KliQWoYt q4VeXvtifYqRYswvlya2y7ZxZ9A+z8m6oiH4DgO49+ZC2JukEyZ1xHFqbxNelfetAzAE YNDQ== MIME-Version: 1.0 X-Received: by 10.152.203.162 with SMTP id kr2mr40727737lac.57.1436019532823; Sat, 04 Jul 2015 07:18:52 -0700 (PDT) In-Reply-To: References:

Date: Sat, 4 Jul 2015 14:18:52 +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 t64EIxkk030212 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 Vladimir, can you please elaborate a little? On Sat, Jul 4, 2015 at 1:25 PM, Evan Foss wrote: > 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/ -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/