On May 6, 2010, at 3:42 PM, Windell H. Oskay wrote: >> Too large ever to assemble. > > Right. Your suggestion is that EVERY SINGLE PERSON should build a full > separate heavy symbol library for EVERY SINGLE PROJECT,
Oh, I reuse symbols from project to project. Don't you? > and yet a single > community-built database is too large of a concept to even consider. A really big project needs 100 symbols. But the majority don't need to be constructed from scratch. It's not a big deal, at least for me. Takes a lot less time to make an IC symbol with DJ's web thing than it takes to figure out which IC best fulfills the requirements. And customizing an existing symbol is even quicker. But I measure trouble with a watch, while apparently others measure it in less objective ways. A community database would need trillions of symbols when the combinatoric possibilities are considered. Now how big is the community that's contributing? There are 41 contributors to gedasymbols. They have contributed 1392 symbols. That's a measure of the capacity of this community. Now, I'm not disparaging that effort, and indeed I will continue to contribute to it and exploit it. How about you? But I have no illusions that this will solve the whining about symbols, even if we could enlist every EE in the entire world to contribute. > Riiiight. > > >> That shows a complete misunderstanding of the nature of the problem. > >> But don't pollute the toolkit with functions that [...] > >> You don't understand that [...] > >> Perhaps to those of us with EDA experience [...] > > > To everyone else-- including those with EDA experince --having a set of > symbols to start with and customize is a known and effective solution. And that's exactly what we have. But having a set of symbols for every likely use is impossible. Ditto for a "database" that represents their attributes (it's really the same thing, just packaged differently). > > Your insults don't change the fact that something that adds great value to > 90% of users without removing functionality is a net gain. But something that leads them down a dead end path is a loss. > But we know > you're not interested in solutions. Obviously. Because nobody but you > understands the problems. We're all too stupid to understand and believe > in your one true completely-adaptable-to-everything workflow as the > solution to everything. > > You've made it perfectly clear time and again that you're opposed to new > features just on the basis that (to paraphrase), "features are bad." > Fine-- you're absolutely welcome to your opinion. Here's my opinion: you > should recompile your gEDA programs with all of code commented out. As > the limit of features goes to zero, you can finally have your perfect EDA > suite-- perfectly scriptable and 100% flexible. The perfect toolkit. You misrepresent my position. I've contributed several gnetlist back ends to the project. And there are a couple of useful scripts in my gedasymbols area. But these actually work, and solve the problems I intended to solve with them. Cute features leading to dead ends (although unfortunately very common in modern software) are not an advance. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
