Mail Archives: geda-user/2016/01/02/10:44:59
The idea behind Xorn is to give gEDA a good, solid scripting foundation.
With "scripting" I primarily mean "having people write code which operates
on gEDA files", not "extending the gEDA user interface".
I was motivated to start working on this when I tried to write a small
program processing a schematic, and I was basically stuck with two
options: either to use libgeda in my program (which is kind of unwieldy
for this purpose as it is more "the common parts of gschem and gnetlist
pulled out into a separate code base" than a general-purpose library), or
to write the program in Scheme and run it from inside a gEDA application.
This led me to
Design goal 1:
All relevant gEDA functionality should be available as one or multiple
libraries which can be used in other programs without having to run a gEDA
application.
With "relevant" functionality I mean anything which is useful without a
GUI, and which the calling program can't easily do itself. That is, the
library should have functions for e.g. reading and writing a file from/to
disk or from/to a pipe and for creating a netlist, but not for scrolling
the window (because that isn't a useful concept without a GUI), or for
connecting two net objects (because the program can easily do that
itself).
The GUI programs would then basically be frontends to this library, and it
would be easy for them to access different parts of the library, for
example to allow selecting all components connected to "GND" in gschem.
But that isn't enough. You would want to run a small program operating on
gEDA files (a "script") from inside an application too; and this shouldn't
be restricted to writing the file, running the script, and then reading
the file again.
Design goal 2:
It should be possible to run a gEDA script from inside a gEDA
application and having it operate on the file opened in the application in
memory.
This implies that there has to be a strictly defined in-memory
representation of all contents of a file on which both the application and
the script can rely. In order for them to be able to co-operate on the
data on equal terms, there must not be any fields or ctors/dtors specific
to either the application or the script in the data.
Access to the data is arbitrated by a dedicated (part of the) library.
Since the applications are written in C and the scripts most probably are
not, this library should have a C interface, and there should be bindings
from the C interface to the languages in which the scripts are written.
(As a nice side effect, it turned out that I could design the library
interface in a way that allowed relpacing the current straightforward
implementation with a more optimized one should the need arise, for
example if gEDA should ever be used for circuit design.)
None of this is restricted to gEDA/gaf (or even gEDA), and none of this is
restricted to Python. I chose gEDA/gaf as a starting point because I knew
it better than PCB, but it would be logical to extend this approach to
PCB, and in fact having a common way of describing things would greatly
help with gEDA/gaf <-> PCB integration (and with anything that needs to
access both schematic and layout). I chose Python for parts of the
implementation because it was the least bad way to do things, and although
the loading/saving and netlisting functionality is written as a Python
module, I'm intending to write a back-binding library which allows C
applications and language bindings to access them as native C functions.
There seems to be some confusion about what Xorn is, and what it's not.
This is probably due to the fact that it's living in a separate codebase,
which gives the misleading impression that it's a new library. It's not:
xorn.geda is (a growing subset of) the actual libgeda code, refactored and
fitted with a standard interface so it goes with the above design goals.
In fact, it's very similar in scope (but not in implementation) to
Vladimir's approach: clean up the core and make it more accessible while
keeping the function intact.
It is also not an attempt to replace Scheme with Python. Xorn uses Python
as a high-level programming language alongside C in which those parts of
the library are written which would be too cumbersome to write in C (have
a look at the original netlister code to see what I mean). There are
indeed some places where gEDA/gaf uses Scheme which I think would be more
appropriate to do in Python (the main code driving the application) or in
an entirely different way (configuration files), but that is a different
issue. Also, since Guile doesn't appear to have Python bindings and it
would have been kind of redundant anyway, I didn't implement a Scheme GUI
in the refactored netlister. Guessing from the feedback I received on the
mailing list, this might be a feature worth adding.
- Raw text -