delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/02/10:44:59

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sat, 2 Jan 2016 16:44:37 +0100 (CET)
From: Roland Lutz <rlutz AT hedmen DOT org>
To: geda-user AT delorie DOT com
Subject: [geda-user] What Xorn does, and why it does it like that
Message-ID: <alpine.DEB.2.00.1508271146310.4001@lichen>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com

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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019