Mail Archives: geda-user/2015/07/04/10:19:10
Vladimir, can you please elaborate a little?
On Sat, Jul 4, 2015 at 1:25 PM, Evan Foss <evanfoss AT gmail DOT com> 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 <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/
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
- Raw text -