geda-developers team mailing list archive

[Vladimir Zhbanov <vzhbanov@xxxxxxxxx>]

On Thu, Sep 17, 2015 at 09:43:01AM -0400, Evan Foss wrote:
...
> > 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).
> 
> Vladimir I am not saying your project you described is wrong. Just
> that letting people advance the projects C or python infrastructure is
> not getting in the way of it.
Fair enough.

> 
> On Tue, Sep 15, 2015 at 10:55 PM, Vladimir Zhbanov <vzhbanov@xxxxxxxxx> wrote:
> > On Tue, Sep 15, 2015 at 10:32:45PM +0000, Evan Foss wrote:
> > ...
> >> What were your thoughts about modularity?
> >
> > Using SCM_DEFINE everywhere, making sure all C functions have guile
> > mates. Making gnetlist, gschlas, gsymcheck and all to be a guile modules
> > which the user could use everywhere, say, just by writing
> > (use-modules (geda netlist))
> 
> from https://lists.launchpad.net/geda-developers/msg00252.html
> 
> No to mention that the other freshly minted gEDA admin does not agree
> with your desire to make the *whole* project scheme.
It is already whole in Scheme (if I understood you correctly). All major
geda-gaf programs have built-in guile. That doesn't prevent C and, I
believe, other bindings. I just want to make more C functionality be
available in guile scripts (like renumbering functions, as Hannu
requested) without rewriting them actually in Scheme (though sometimes
rewriting in high-level language makes things more intuitive, flexible
and modificable). That would make adding or varying functionality much
easier.
> 
> Vladimir
> > It's frustrating for me that the core functionality of libgeda/gschem is
> > written in C (e.g. reading and writing of files) which makes it
> > unmaintainable (see, for example, what bugs are marked as critical at
> > https://bugs.launchpad.net/geda) for a long time. I believe, it would be
> > easier to fix them if the geda-gaf language was really Guile/Scheme.
What's wrong with this?

> 
> Ed
> > To increase the number of developers on the project, we would need to find people interested in EDA, willing to contribute to open source, and know C or Guile/Scheme.
> >
> > I speculate that way more people know C than Guile/Scheme, and if we moved to project over to completely Guile/Scheme, would reduce the number of candidates for developers.
> >
> > Many job openings for electronic, firmware, and embedded engineers want some form of scripting language, like Python or Ruby. Many careers working close to the hardware level use C.
> >
> > I believe using languages that gEDA users would use in the course of their careers would increase the number of potential developers.
> >
> > The likelihood that this thread, including the input from all the developers and users, sets direction of the gEDA is slim. One developer either dives in and changes things, or goes somewhere else and starts a new version. I'd like to see
> > some process that resolves the conflicting priorities of the community, can set direction, and allow multiple developers to coordinate as a team.
> 
> Both from http://www.delorie.com/archives/browse.cgi?p=geda-user/2015/07/07/13:20:23
> 
> Yes Peter Brett also likes scheme but respectfully he is leaving.
All this is about consensus. I proposed a solution that already has been
considered and you can find the ideas in our wiki: using gobject's and
already made bindings (see wikipedia for links).
> 
> > 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'.
> 
> Everything starts with 1 developer.
> 
> > 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:
> 
> We need less emphasis on scheme. I am not saying it needs to go, just
> that we need to have an alternative.
I might say this about any other language.

> 
> >   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.
This one.
Two connected orthogonal arguments, unrelated to each other:
1. having many scripting languages is a bad idea  (that is, Guile must go off)
2. Nim must have an ability to process gEDA files (my first impression: why
guile? it restricts any other languages, e.g. Nim)
> >
> >       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).
> 
> At some point I want to try that.
I would agree with using his library if that had been done honestly,
after consensus among the developers. Now I don't ever know what the
geda-gaf admin status is for and what it changes if other people (hi, DJ
and Markus) decide who and where must drive the development in the
project (it's about so named "levels of trust" here) and have all levers
to move it the way they want without asking anybody else. Although I
appreciate their work, I feel this behaviour not be fair. 

Cheers,
  Vladimir