Mail Archives: geda-user/2015/09/17/06:35:52
On Thu, 17 Sep 2015, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> xorn was added into master without asking current developers
I did ask [0], and I waited a fair time for feedback before pushing things
further. Since the situation appeared to have come to a standstill as
with so many proposed changes, I decided to move forward and merge the
changes into master.
> despite of the objections
Which objections do you refer to? You wrote[1]:
> I'm emerging here as an opponent to you, Roland, John Doty, Kay-Martin
> and all others, who discourages users from trying to use new Scheme
> script possibilities Peter Brett have added to the project
I'm definitively not discouraging people to use Scheme. I'm also not
trying to replace Scheme with Python as you seem to assume; Scheme is used
as a scripting language which allows users to extend the applications
while I'm using Python for the implementation, instead of C. In fact, I
considered adding Guile scripting to Xorn as well (but decided against it
because there don't seem to be usable Python bindings for Guile).
In another post [2], you wrote:
> Exactly one developer (Roland) works on its python branch and has a
> support of some users in the list who always keep repeating 'guile is
> wrong'.
I'm not "working on the Python branch"; I'm trying to improve gEDA
inside-out by giving it a solid foundation. This includes strict
separation between functionality and user interface (command-line or GUI)
as well as making that functionality readily available as a library.
From a library-user point of view, Guile is indeed wrong. I acknowledge
your vision of turning the gaf applications into Guile modules, but I
think that's wrong for two reasons:
1.) Libraries should be usable from any language. Having several
different scripting languages in gEDA may be a bad idea (I'm not sure, but
I tend to agree with you), but there's really no reason why a Nim program
shouldn't be able to process gEDA files.
The easiest way to achieve this would be to write the library in C,
so it's easy to create bindings for any language. This wasn't feasible
with the netlister, so I took measures to come as close to this as
possible (by writing a C interoperability library and providing a
(work-in-progress) back-binding library).
2.) Rather than turning an application as a whole into a library, it
makes more sense to isolate the "productive" core from the rest of the
application which parses configuration files and command-line options,
displays a user interface, etc.
You can see this separation with the "xorn netlist" command: the
package xorn.geda.netlist contains the "productive" netlisting
functionality and does not make any assumptions about configuration
options, search paths, and so on. These are all parsed and passed on by
xorn/src/command/netlist.py, the actual command-line utility.
> How will this encourage any dev like me who've invested their time on
> learning current gschem internals and Scheme in order to try to make
> things better?
I invested time in learning the current gschem internals, too. The fact
that things are currenty implemented in a certain way doesn't mean there
isn't a better way, though.
> Roland preferred not to notice
I did notice you, and I responded to your criticism. It's just that right
now, you seem to be the only person seriously opposed to merging xorn/
into the main repository, and your point seems to be mainly that you
prefer Guile to Python. Please, take the time to understand Python and
Xorn, as I did with Scheme and the Guile interface--it's really not as bad
as you think, and our ultimate goals aren't that different.
Roland
[0] http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/09/04/05:00:51
[1] http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/09/05/17:02:30
[2] http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/09/05/17:40:22
- Raw text -