geda-developers team mailing list archive

[Roland Lutz <rlutz@xxxxxxxxxx>]

On Thu, 17 Sep 2015, Vladimir Zhbanov (vzhbanov@xxxxxxxxx) [via geda-user@xxxxxxxxxxx] 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