X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Injected-Via-Gmane: http://gmane.org/ To: geda-user AT delorie DOT com From: Kai-Martin Knaak Subject: Re: [geda-user] Re: refdes renumber Date: Sat, 08 Jun 2013 13:47:09 +0200 Lines: 85 Message-ID: References: <82BD0858-A229-4675-A3BD-17C7A2056654 AT jump-ing DOT de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet AT ger DOT gmane DOT org X-Gmane-NNTP-Posting-Host: a89-182-130-170.net-htp.de User-Agent: KNode/4.4.11 Reply-To: geda-user AT delorie DOT com Markus Hitter wrote: > People no longer care about non- > blocking bugs, don't look at patches and those doing development > usually keep the result in their own locker out of an totally > unfounded fear to mess something up or, worse, don't even get the > idea their work would be welcome. Well, geda is not exactly known to happily accept contributions by people from outside an inner circle of core developers. Patches tend to not be applied, even if they were reported to fix the respective problem. Many bug reports, even ones with patches, stay without any response whatsoever. New features get relegated to be "plugins" rather than integrated into the main application. That way, they tend to break silently when the main branch moves ahead. The plugins are not delivered as part of geda. They have to be downloaded and compiled individually by the user for every version of the application. This drastically decreases the already small user base. In addition, there is a strong psychological signal saying: "This is a closed shop. Please don't expect us to accept your contributions" > I see this especially with > projects trying to do high quality work, not so much with chaotic > development models used by Linux & Co. I am not convinced that open source development is generally more chaotic than closed source. Just because you don't see less than optimal structures from the outside does not mean, everything is fine behind the veil of a binary blob. There are plausible reasons that even the opposite may be true. The very fact, that every code path is explicitely visible to the public provides a motivation for excellence. > That general note said, please simply commit this renumber command. > We have source code management, so things can't get worse. I say so > without even investigating what would be wrong with the current > renumber capabilities. My most pressing wish with regard to renumber scripts: Play nice with multi part sympols. It is good practice to split power pins or function blocks of integrated components into separate symbols. Thy all share the same value of the refdes attribute. This sameness of refdes values lets gedalib know that two symbols are meant to refer to the same component. The same applies to slotted symbols. The current renumber script in gschem ignores this. It assumes, that no refdes shall ever be dupplicated and alloates individual refdeses no matter what. Since I use symbols with split power pins in almost every schematic, this makes automatic renumber a lot less useful than it could be. A simple low level way to improve the situation would be an option to just keep duplicate refdeses duplicate. E.g, two components with refdes=U5 would both end up with refdes U=13. Of course, this simplistic approach also leaves accidental dupliates intact. It still would be a major improvement for my kind of projects. Some more elaborate logic might come handy to properly differntiate between deliberate and accidental duplicates. The symbol already "knows" about the number of slots. So the renumber script can check weather or not duplicates are consistant with slotting. This concept can be extended to split symbols: Add attributes to the symbol that give hints on possible associated symbols. The symbl opamp.sym might contain an attribute that points to a symbol with the proper power pins. Like this: associated=opamp_pwr Similarily, the symbol opamp_pwr.sym would contain an attribute: associated=opamp In an ideal world, there would also be clues wheather or not an associated symbol is optional or should be enforced. Anyway, even the very simple option to not touch duplicates at all would improve my renumber experience a lot. ---<)kaimartin(>--- -- Kai-Martin Knaak