geda-developers team mailing list archive

[Evan Foss <evanfoss@xxxxxxxxx>]

On Thu, Sep 17, 2015 at 6:33 AM, Roland Lutz <rlutz@xxxxxxxxxx> wrote:
> 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).

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.

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.

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.

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.

> 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.

>   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).

At some point I want to try that.

>   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
>
>
>
> --
> Mailing list: https://launchpad.net/~geda-developers
> Post to     : geda-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~geda-developers
> More help   : https://help.launchpad.net/ListHelp



-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/