Re: gEDA-user: Light? Heavy? Reuse...

[John Doty <jpd@xxxxxxxxx>]

On Jan 21, 2009, at 10:58 AM, DJ Delorie wrote:

>
>>> Certainly a good idea, except that it doesn't offer a way to feed- 
>>> back
>>> to gschem for things that the user *must* (in their opinion) select.
>>> For example, what resistor values are available?  In what  
>>> tolerances?
>>> If you pick a 10uF capacitor at 10v, what's the smallest package it
>>> comes in?
>>
>> That's why when I do this the next screen over is a Digikey search.
>
> When you have a corporate parts database, that's not an option.

If you have a corporate parts database, there's got to be *some* way  
to view it. Whatever that is, put it in view as you design. We aren't  
going to come up with a universal gschem-centric facility for this  
anyway.

>
>>>   Like I've said before, the schematic is more than topology
>>> - it's design.  Some attributes are intrinsic to the design, like
>>> resistor/capacitor values, and should (according to some folks at
>>> least) be included with the schematic.
>>
>> Yes, we should support that possibility, and we do. But we should not
>> cater to the desire for a tangled flow, or a toolkit that isn't
>> easily scriptable.
>
> Simplicity means that gschem should have access to all the attributes,

Access, but minimize its internal model of how they relate. When it  
has a model of more than topology, anyone who writes a script to  
process schematics must understand what that model is. The file  
format no longer is definitive: one must understand how the symbols  
relate internally within gschem.

> not just the few that you think deserve to be on the schematics.

I put all kinds of attributes, including some with local names, in  
schematics. But to gschem, they are just text. That's the flexible  
approach. Don't model the design flow in gschem, only circuit  
topology. Give advice to the downstream tools with attributes. That's  
the flexible approach.

>>> The extra database contains (or could contain) all this information.
>>
>> Millions of entries. Impractical for us to maintain.
>
> No worse than what we already have to manually enter into schematics
> now.

Putting it into our existing "database" format (symbol files) is not  
that hard, and you only have to create the specific things you need.  
While a database containing every alternative that could meet a spec  
is orders of magnitude more complicated.

>
>>> It's up to the user to specify *enough* attributes to uniquely
>>> identify a specific physical part (in the pcb case at least), or in
>>> combination with a BOM tool or preferences ruleset, at least be able
>>> to pick something appropriate.  However, IMHO the user needs  
>>> access to
>>> these attribute options in gschem.
>>
>> Why? gschem would just pop up some window for this anyway. Why not
>> "stand on the shoulders of giants", use the web here?
>
> Using the web to type in "4.7k" for a resistor is just silly.

I agree. But now, I want a 4.7k that can withstand 300V pulses and  
dissipate 1W. What package choices do I have? How do I even write the  
search predicate?

> Besides, with the right back-end API, we *could* use the web as our
> "database".
>
>>> The key to heavification is that some of the inferred attributes
>>> include the pin name-to-number mapping.  This lets you use really
>>> light symbols without the "transistor problem" we currently  
>>> have.  But
>>> even then, users may want to direct this slotting from within  
>>> gschem.
>>
>> And we should resist the temptation to give in here.
>
> What, you don't want the user to be able to control slotting?

Of course the user should control slotting. THe problem is that  
gschem should minimize its *model* of slotting. The current model is  
both complex and wrong: it can't handle power pins or heterogeneity,  
overloads pinseq, and confuses most users.

>
>> "A program should do one thing well".
>
> But let's not limit it to just doing that one thing, or define the one
> thing too narrowly.

Every way the tool models the process reduces flexibility, usually in  
a way unanticipated by the programmer. "Nobody will do that" ...

>
> The whole "do one thing well" saying is a trap - I wish you'd stop
> using it, since one can define the "one thing" at any level, making it
> a meaningless rule.

I think it can be discerned. Ask "Is this feature common to the  
various applications of the tool?" If the answer is "yes" or  
"mostly", that feature is part of the "one thing".


> I say the one thing is "design circuits", you say
> the one thing is "draw topologies".

But gschem is useful, and used, for a wide variety of things that  
come under the description "design circuits". Sometimes I'm sketching  
a test circuit I'll put on perfboard later in the day. Sometimes I'll  
design VLSI. One customer wants the BOM, as delivered, to contain  
values and specs: they figure out part numbers and footprints.  
Another wants me to select these.

The only thing these flows have in common is the capture of topology,  
the annotation of the elements of said topology with attributes, and  
the graphical presentation of the results. But the data products down  
the road are completely different. To maximize flexibility, gschem  
should have as little knowledge of those data products as is  
practical. The other details of the flow should be handled by filters  
or plugins.

>
>> Every complex behavior added to gschem will make it harder to
>> manipulate the design files with other tools, because those tools
>> will have to satisfy the inevitable constraints the complexity puts
>> on the relationships among the data objects.
>
> But a certain amount of complexity is needed to make it a useful tool.
> Otherwise, people would just use a text editor to input schematics.
>
>> Right now, gschem is almost completely ignorant of what attributes
>> mean, and I would hope this would continue to be the case.
>
> Like refdes?
>
> Anyway, my scheme doesn't change what gschem knows about.  It just
> provides a way for attribute values to come from somewhere other than
> the user's keyboard.
>
>> As we have seen with slotting, once gschem starts to model the
>> meaning of an attribute, all kinds of unanticipated problems arise.
>
> But we *need* slotting.  It's something people complain about all the
> time.  We need *more* complexity behind the scenes to *reduce*
> complexity for the user.

I disagree completely. The only approach that I think workable  
without being too inflexible for some user is some variant on a "(sub) 
symbol per slot" approach.

>   We need to be able to control slotting and
> pin swapping from both pcb and gschem, because people keep asking for
> it.

In different ways. The problem is that gschem incorporates too much  
knowledge of slotting, and that gets in the way of any approach that  
doesn't fit the model. And there isn't just one approach that is wanted.

> *I* would like better control over pin and gate swapping.  If you
> don't want such control, fine, but don't demand that others make the
> same sacrifice that you make voluntarily.

I want it too. The way to get it is to have a *simpler* mechanism,  
minimizing the ways the user can trip over unwanted assumptions in  
gschem.

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