Mail Archives: geda-user/2016/01/02/15:21:41
--047d7b5d3e64b5844705285fa19d
Content-Type: text/plain; charset=UTF-8
This has a lot in common with my more modest goal of making pcb file format
more universally readable using YAML. So far as I can see these different
approaches to increasing accessibility of the format shouldn't preclude on
another, and the only risk is the confusion that comes from having too many
different ways to do similar things. In terms of implementation pcb-side
there is a little bit of overlap.
If it isn't too controversial, my next branch is going to involve
separating the parser from the pcb innards, as preparation for adding an
equivalent YAML format. This was discusses previously together with Lev's
proposed extensions (which could be implemented later, as their
implementation in terms of internal data structures permits). I'd rather
not do anything that might make things harder for you later, as I really
like the sound of the Xorn approach. I'll post the name of the branch and
welcome any early feedback you might have about it.
Britton
On Sat, Jan 2, 2016 at 6:44 AM, Roland Lutz <rlutz AT hedmen DOT org> wrote:
> 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.
>
>
--047d7b5d3e64b5844705285fa19d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>This has a lot in common with my more modes=
t goal of making pcb file format more universally readable using YAML.=C2=
=A0 So far as I can see these different approaches to increasing accessibil=
ity of the format shouldn't preclude on another, and the only risk is t=
he confusion that comes from having too many different ways to do similar t=
hings.=C2=A0 In terms of implementation pcb-side there is a little bit of o=
verlap.<div><br></div><div>If it isn't too controversial, my next branc=
h is going to involve separating the parser from the pcb innards, as prepar=
ation for adding an equivalent YAML format.=C2=A0 This was discusses previo=
usly together with Lev's proposed extensions (which could be implemente=
d later, as their implementation in terms of internal data structures permi=
ts).=C2=A0 I'd rather not do anything that might make things harder for=
you later, as I really like the sound of the Xorn approach.=C2=A0 I'll=
post the name of the branch and welcome any early feedback you might have =
about it.</div><div><br></div><div style=3D"">Britton</div><div><br></div><=
div><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, =
Jan 2, 2016 at 6:44 AM, Roland Lutz <span dir=3D"ltr"><<a href=3D"mailto=
:rlutz AT hedmen DOT org" target=3D"_blank">rlutz AT hedmen DOT org</a>></span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">The idea behind Xorn is to give gEDA a g=
ood, solid scripting foundation. With "scripting" I primarily mea=
n "having people write code which operates on gEDA files", not &q=
uot;extending the gEDA user interface".<br>
<br>
I was motivated to start working on this when I tried to write a small prog=
ram processing a schematic, and I was basically stuck with two options: eit=
her to use libgeda in my program (which is kind of unwieldy for this purpos=
e as it is more "the common parts of gschem and gnetlist pulled out in=
to 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 m=
e to<br>
<br>
Design goal 1:<br>
=C2=A0 All relevant gEDA functionality should be available as one or multip=
le libraries which can be used in other programs without having to run a gE=
DA application.<br>
<br>
With "relevant" functionality I mean anything which is useful wit=
hout a GUI, and which the calling program can't easily do itself.=C2=A0=
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 GU=
I), or for connecting two net objects (because the program can easily do th=
at itself).<br>
<br>
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 exampl=
e to allow selecting all components connected to "GND" in gschem.=
<br>
<br>
But that isn't enough.=C2=A0 You would want to run a small program oper=
ating on gEDA files (a "script") from inside an application too; =
and this shouldn't be restricted to writing the file, running the scrip=
t, and then reading the file again.<br>
<br>
Design goal 2:<br>
=C2=A0 It should be possible to run a gEDA script from inside a gEDA applic=
ation and having it operate on the file opened in the application in memory=
.<br>
<br>
This implies that there has to be a strictly defined in-memory representati=
on of all contents of a file on which both the application and the script c=
an rely.=C2=A0 In order for them to be able to co-operate on the data on eq=
ual terms, there must not be any fields or ctors/dtors specific to either t=
he application or the script in the data.<br>
<br>
Access to the data is arbitrated by a dedicated (part of the) library. Sinc=
e 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 t=
he C interface to the languages in which the scripts are written.<br>
<br>
(As a nice side effect, it turned out that I could design the library inter=
face in a way that allowed relpacing the current straightforward implementa=
tion with a more optimized one should the need arise, for example if gEDA s=
hould ever be used for circuit design.)<br>
<br>
<br>
None of this is restricted to gEDA/gaf (or even gEDA), and none of this is =
restricted to Python.=C2=A0 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 he=
lp with gEDA/gaf <-> PCB integration (and with anything that needs to=
access both schematic and layout).=C2=A0 I chose Python for parts of the i=
mplementation because it was the least bad way to do things, and although t=
he loading/saving and netlisting functionality is written as a Python modul=
e, I'm intending to write a back-binding library which allows C applica=
tions and language bindings to access them as native C functions.<br>
<br>
<br>
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 codeba=
se, which gives the misleading impression that it's a new library.=C2=
=A0 It's not: xorn.geda is (a growing subset of) the actual libgeda cod=
e, refactored and fitted with a standard interface so it goes with the abov=
e design goals. In fact, it's very similar in scope (but not in impleme=
ntation) to Vladimir's approach: clean up the core and make it more acc=
essible while keeping the function intact.<br>
<br>
It is also not an attempt to replace Scheme with Python.=C2=A0 Xorn uses Py=
thon 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 (hav=
e a look at the original netlister code to see what I mean).=C2=A0 There ar=
e 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 is=
sue.=C2=A0 Also, since Guile doesn't appear to have Python bindings and=
it would have been kind of redundant anyway, I didn't implement a Sche=
me GUI in the refactored netlister.=C2=A0 Guessing from the feedback I rece=
ived on the mailing list, this might be a feature worth adding.<br>
<br>
</blockquote></div><br></div></div></div></div>
--047d7b5d3e64b5844705285fa19d--
- Raw text -