geda-developers team mailing list archive

[Evan Foss <evanfoss@xxxxxxxxx>]

On Thu, Sep 17, 2015 at 3:14 PM, Vladimir Zhbanov <vzhbanov@xxxxxxxxx> wrote:
> 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?

Everything Ed said in his reply I agree with and I think most people
probably would too. For long term project health we have to
deemphasize scheme use.

I am not opposing what you are doing, just saying that in the long run
I worry that making the core use scheme when new developers for it are
rare is dangerous.

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

Again I was not opposing your project. Just pointing out you are a lot
more bullish on scheme than it seems everyone else is.

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

I can't swing a cat in Cambridge Ma. with out hitting someone who
knows C. Heck it was a required course when I was in college. Scheme
is far lower in adoption. Again not saying you should not do your
project.

>>
>> >   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 line above that you are replying too. I don't recall writing that.
I think it was someone elses.

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

1. The first time you miss attributed a quote to me I was ok but this
is the second time and I am getting irritated. Again this was Roland.
2. You were the one decenter on the thread "developer excitement? was
Re: [geda-user] gEDA/gschem still alive?" when the subject was raised.
I assumed that was a consensus. Peter was totally absent at the time.


> Cheers,
>   Vladimir
>
> --
> 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/