On Dec 31, 2010, at 8:37 AM, Peter Clifton wrote: > On Wed, 2010-12-29 at 13:18 -0700, John Doty wrote: > >> Divorce gEDA from pcb. Create a schematic plugin for pcb, since that >> seems to be what pcb users want. The flexibility of the >> gschem/gnetlist flow is unnecessary to hobbyists. The current >> developers are dangerously pcb-centric. > > ARE there any "current" gEDA developers? > > That is slightly rhetorical, as I know Peter Brett is doing some > thankless, but HUGELY important work on refactoring the gschem drawing > code into a separate library.
Yes, and I'm successfully running his branch here. This is indeed important. Go, Peter! > > This library will be important to the project as it opens the > possibilities for creating external previewers, thumbnailer's, library > managers, command line printing tools etc.. which don't require gschem > to render graphics. Some day I hope PCB can do this too. > > Peter has also done work on guile APIs recently. (I'll confess not to > have followed that particularly closely, but it was not in any way PCB > specific). You think it wasn't, but the habit of thought that considers pcb as the only back end worth considering has colored it. In particular, we've sparred over the nature of the API: Peter doesn't understand that there is *no* invariant semantic processing suitable for all flows. The midlayer should start at parsed, unprocessed schematics. And as a gnetlist back-end writer, Peter's Guile code scares me. He avoids pure functional programming wherever possible in the name of efficiency. This is dangerous, as it is difficult for the user to anticipate where his side effects might bite if they reuse his code. As somewhat who grinds very large projects through gnetlist, I would be the first to ask for efficiency to be given priority if it was a significant problem. It isn't. But Peter also has some very good notions about Guile code. I recently took some of his suggestions as input to a refactoring of my Osmond back end. The whole thing collapsed to just 18 LOC, and I think his suggestions also improved readability despite my initial skepticism. > > > Without offending anyone I hope, I think it would be fair to say there > is ONE "current" gEDA developer, and I think you would struggle to point > out anything detrimental Peter Brett has done to the project. Well, Peter, at least, thinks of you as a developer. And there's DJ, who is certainly influential, energetic, and brilliant, but has a dangerously narrow focus. Then there's Patrick Bernaud. Bas Gjeltes and I tried to contribute a patch for the attribute censorship bug, but Patrick grabbed it, unfactored my Guile code, found a problem that broke drc2, and then dropped it. Is Patrick a developer? At least, he's a gatekeeper. Maybe refactoring and fixing the drc2 bug will be my New Year's day project. Then we'll see if this problem can *ever* be solved. > > His dedicated work on thankless tasks have helped keep things alive at a > time when gEDA development has / had otherwise completely stagnated. That kind of argument will never move me. There is no value to fixing what isn't broken. There's nothing wrong with stagnation of code in itself (the stagnation of TeX is a sign of near perfection). Peter's narrowly focused on code, not broadly focused on application. That has its good points, but also its dangers. Coding purely for code's sake on a toolkit that's in successful production use is not generally a good idea. Peter's current work must stand on the importance of refactoring as a means for resolving the conflicts between the various ways we use (and want to use) gEDA, I think. And I expect it will be a good thing by this criterion, but that won't come automatically. > > (Yes, Peter B and I are friends, so I'm biased - but I think this all > bore saying.) I think we can all be friends. Disagreement does not imply malice. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
