Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")

[John Doty <jpd@xxxxxxxxx>]

On May 6, 2010, at 2:13 PM, DJ Delorie wrote:

> 
>> Impractical in general. Just reproduces the heavy symbol problem
>> behind yet another interface. The software is easy, assembling the
>> data is impossible.
> 
> No, it doesn't.  It's a way to populate your project specific database
> from a much larger field of parts,

Too large ever to assemble.

> or navigate through your project
> specific database once it's created.  It's a way to look at a large
> data set and extract a smaller one from it.

Show me that large data set. Concretely. Then worry about the (orders of magnitude smaller) job of using it constructively. But don't pollute the toolkit with functions that can never be practical, because the database to actually use them will never exist.

Again, we already suffer from this problem. The symbol placement GUI implicitly assumes the library contains the heavy symbol you need, and guides newbies into a low productivity trap thereby.

>  It's a way to
> synthetically create a heavy symbol database that's orders of
> magnitude larger than what we'd be able to do with
> one-symbol-per-partnumber heavy symbols like we (and you) use now.
> 
> For example, look at any Digikey catalog (printed, not web).  They
> *don't* list all available part numbers, they provide
> fill-in-the-blank part numbers for things like resistors and
> capacitors.  Wouldn't it be nice to have a plugin that could
> synthesize all those part numbers on demand?  So one resistor symbol
> and a couple of rules gives you thousands of available heavy symbols,
> with little overhead?

There are already heavy symbol generators kicking around for this case. But consider that even with the occasional fill-in-the-blank form, the printed catalog is over 1000 pages of bifocal-challenging type. And Digikey only has a subset of what's out there. And what they have changes every day.

> 
> Now, you can put the one symbol and the few rules in your project
> specific database if you want, but I'd rather have one central
> location for all my parts.  However, my idea precludes neither way.
> 
>> The package to use for a 4.7k 1/10W 5% resistor and a Digikey part #
>> for it.
> 
> That doesn't let me say "use any 4.7k resistor, and let someone else
> figure out what part (or model) that is".

It lets you defer that decision to as late as generally possible, just before design export to BOM and layout.

>  John, in your case, the
> database *is* your project-specific database.  YOU still have the
> problem of creating those heavy symbols anyway, choosing among them,
> and making design changes at varying steps along the flow.  Why won't
> you let us help you make your job easier?

Because I don't find this credible. You don't understand that turning the code you want to write into a practical facility requires additional work beyond the code. This is a massive clerical problem, orders of magnitude larger than writing the code.

> 
> Even if we all used your ideal workflow (which we don't), we still
> want to easily solve problems like "I want an LED.  What colors do I
> have?"  without having to go groping through a directory looking at
> every possible LED we have and somehow remembering what color options
> were available.
> 
>> is practical. But that kind of mapping can already be done in gschem
>> to the extent it makes sense. It's when you want to make wholesale
>> decisions downstream that we have no mechanism.
> 
> So... I try to add such a mechanism, and you tell me it's the wrong
> thing to do?

Of course. Because the mechanism will be trivial, but collecting the data to back it up is impossible.

Consider the following recent thread:

On Apr 24, 2010, at 7:46 PM, al davis wrote:

> On Saturday 24 April 2010, kai-martin knaak wrote:
>> There should not be a need to search for specific models for
>> getting started  with basic circuits in the first place. The
>> models don't have to be exact. But they need to be available
>> right away.
>> 
> 
> Ah ..  there's a good idea ..  "don't have to be exact" .. they 
> never are ....   Not detailed, but just good enough for a 
> beginner. ......  Now we need a volunteer to do it.
> 
> Have things like a generic parameterizable op-amp. .. with 
> parameters like gain, gbp, and so on.
> 
> Can you make a list of the ones that should be included?

The respondents all had wildly different ideas of what that implied, and even with just a handful of responses, it was clear that a very large effort would be needed. I actually contributed three simple opamp models, and the next question was "how about an OP07?" There's no satisfying the users here. This is a huge problem, and the one you want to solve is much larger.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user