Mail Archives: geda-user/2015/09/12/05:53:40.1
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-873903576-1442051215=:2663
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine DOT DEB DOT 2 DOT 00 DOT 1509121147001 DOT 2663 AT lichen>
On Fri, 11 Sep 2015, John Doty wrote:
> On Sep 11, 2015, at 8:06 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
>> An in-memory database? Look at libxornstorage.
>
> I have, and it’s hard to comprehend given the state of the
> documentation. The first time I looked at it, I saw Yet Another OO
> Framework. What’s this for?
Hm. Maybe you got a point here. It's actually quite hard to describe
what a library is for when you're waist-deep in its internals. Let me try
to explain it a different way:
libxornstorage is a C library that defines structs for all necessary
object types (currently schmatic objects), and manages lists of these
structs. By imposing a strict data model on the using application (no
additional fields in the structs, no update triggers, etc.), it makes sure
no application has its own special exceptions on the data model. This
allows a C application (gschem), a Python application (xorn netlist), and
possibly user scripts in arbitrary languages to access the same in-memory
data without having to worry about the other code's implementation details.
Additionally, it allows applications to use a "value-oriented" approach to
file states. This means you can either create one empty "file revision"
and change it as you wish, or you can "finalize" a revision (make it
read-only) and force others to create a copy if they want to change it.
(This copy should obviously be implemented in an efficient way.)
For example, if a user script is called as an action from gschem, the
state before the invocation could be a finalized revision, and the state
the script changes could be a copy of that. After the script finishes,
gschem would use xorn_get_modified_objects etc. to update its display and
associate the previous revision with the last undo step.
>> I'm not "working on the Python branch", and I haven't "created a
>> complete parallel to gnetlist, but based on Python rather than Scheme".
>> xorn-netlist *is* gnetlist.
>
> Not really. I don’t see xorn-netlist replacing gnetlist in projects that
> already use custom Scheme scripts.
That's because xorn-netlist lacks Scheme support, and, admittedly, I
probably won't add it any time soon. Apart from that, it is pretty much
the same code (or rather was, before I started refactoring it) and should
produce identical output (except for a few well-documented differences).
>> I'm gradually shifting the gEDA infrastructure to a more modular
>> design, using C where I have to (for interoperability with any
>> language) and Python where I can (for those implementation parts which
>> don't have to be hand-optimized in C). In the process, I converted the
>> API for netlist backends to Python, but that was partly because there
>> are no Guile bindings in Python, and the code turned out to be much
>> easier this way.
>
> Please continue with xorn as a parallel effort, as you’ve so far done
> with success. Some of us have too much investment in the old geda-gaf to
> switch easily.
That would defeat the whole purpose of libxornstorage. Think of it not so
much as of a traditional library as of a refactoring help. It does
provide some functionality (or rather allows its implementation to do so),
but that's not the point. The library interface is designed in such a way
that, by moving to use libxornstorage, a project is forced to adapt an
internal architecture that allows the kind of intra-process communication
which I outline above.
This is only an implmentation detail; it doesn't affect Scheme or Python
or other user-visible things in any way, and it is also the only kind of
integration which I intend to do in the relatively near future (so calm
down, please :).
On the long term, I'd like to move the functionality that would be handy
to have in a library out of libgeda (which itself isn't in practice usable
for inclusion in other programs) into a new library. Since much of the
functionality of libgeda is high-level and rather cumbersome to implement
in C, I chose Python for that task. This doesn't mean all programs using
that library have to be written in Python any more than that fact that
libxornstorage is written in C means that programs using it would have to
be written in C. In fact, I've already started to write a back-binding
library which allows using xorn.geda from pure C code.
>> The obvious thing would be to continue that scheme for PCB, too
>
> The big difficulty I see here is that geda-gaf is a bottom-up design:
> […] Geda-pcb, by contrast, is top-down with restricted goals and
> capabilities. […] I expect that a xorn-pcb would be as frustrating.
> Unlike geda-gaf, where the frustrations have been rooted in the
> implementation, the frustrations of geda-pcb are rooted in the design.
Maybe extracting the functionality that would be handy to have in a
library is harder from PCB than it is from libgeda, but I don't see any
fundamental problems here. As Nicklas already suggested, pulling out the
file reading/writing code into a library is probably one of the first
steps (though I'd put adapting and using libxornstorage first, considering
the state of the code base, as this may avoid many shudderings later).
Roland
--8323329-873903576-1442051215=:2663--
- Raw text -