Mail Archives: geda-user/2015/07/04/08:21:09
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--
- Raw text -