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:	<alpine.DEB.2.11.1507041329400.8210@nimbus>
References:	<CAM2RGhSkHSm8h571=3GePQUm-HAnxeb7-HCF=p2a+QUzP6rNkA AT mail DOT gmail DOT com>
	<alpine DOT DEB DOT 2 DOT 11 DOT 1507041329400 DOT 8210 AT nimbus>
Date:	Sat, 4 Jul 2015 13:25:05 +0000
Message-ID:	<CAM2RGhSzNfL0yy49ZLhLY-G8+JxRxVnMRqVaoN3OiSzwV8v9oA@mail.gmail.com>
Subject:	Re: [geda-user] libgeda3
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
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

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 <rlutz AT hedmen DOT org> 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/

- Raw text -