On Thu, Sep 17, 2015 at 3:14 PM, Vladimir Zhbanov <[email protected]> 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 : [email protected] > 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/ -- Mailing list: https://launchpad.net/~geda-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~geda-developers More help : https://help.launchpad.net/ListHelp
