On Thu, Sep 17, 2015 at 6:33 AM, Roland Lutz <[email protected]> wrote: > On Thu, 17 Sep 2015, Vladimir Zhbanov ([email protected]) [via > [email protected]] 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 : [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
