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 To: geda-user AT delorie DOT com Subject: [geda-user] What Xorn does, and why it does it like that Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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.