On Fri, 16 Oct 2009 14:36:38 -0600, John Doty wrote: >> Yes, this is exactly the pitfall that my patch fixed, whose acceptance >> you violently and successfully opposed. > > For good reason: it fixed this *particular* symptom, but not the general > problem (the gnetlist front end filters data in ways the back end cannot > control).
Not so. My patch just fixes a completely different general problem: Currently, gnetlist behavior depends on the order of symbols in the file. Making sure, that the output does not depend on the order in the *.sch file cures the power symbol pitfall. It just happens, that fixing the general problem you perceive, could also fix the pitfall. However, this does not make your general problem a superset of the order problem. > It does so in a way that complicates a proper solution. Not so. Sorting the internal list of symbols does not change the data structure in any way. Any code you, would like to add to gnetlist to fix the problem you perceive, still works with a sorted internal list of symbols. No modification whatever is required. The only exception is procedures that explicitly try to differentiate the order of symbols in the file. However, we agree, that no decent back-end should care for the order symbols were entered in gschem. Please stop pointing to downsides where there is none. > offer to collaborate on a proper solution still stands: you've obviously > penetrated the front end C code I did not in the way you imply. In particular, I am completely clueless on how the C code interacts with the scheme scripts. No documentation of this interface crossed my screen. I have not been searching for this, either. > We can fix this together. Successful cooperation with someone, who tends to misinterpret my intentions seems unlikely. >> Who expects a renumber script to distribute symbols with a common >> refdes to several refdeses? > > When you cut and paste bits of circuit from previous projects, you may > want your renumber script to heal the duplicate refdeses. Ok, this is a valid case. There may, or may not be sets of symbols with deliberately identical refdes. There is no way the renumber script can know. The user needs to give hints in some way. One way would be to renumber the copy pasted parts to some range outside the rest of the current hierarchy. Another way would be to tell the script not to worry about identical refdeses. That is behave like renumber behaves now. However, this healing of copy-paste is a special case. Currently, global application of renumber breaks perfectly working schematics with multi part symbols, no matter what. I call this a bug with the potential of a complete show-stopper. Others may call it "room for improvement". Still, you oppose any change with your mantra: > And remember that there are usage scenarios for gEDA that neither > you nor I have yet imagined. ---<(kaimartin)>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user