gEDA-user: Using the power instead of fighting it

[John Doty <jpd@xxxxxxxxx>]

On Sep 27, 2009, at 10:54 AM, Martin Maney wrote:

> I was going to comment on one point, but once you start writing...
>
> On Sun, Sep 27, 2009 at 06:16:42AM -0600, John Doty wrote:
>> More useful and friendly to *what kind* of user? The kind that would
>> prefer spending an hour mousing around to solve a problem once, or 15
>> minutes writing a script to solve it for all time?
>
> I suppose it depends on whether gEDA is only for those who use it for
> hours every day and thus find the cost of learning to and configuring
> things to work just the way they want them an obvious net win, or if
> it's desired for it to be useful to a larger audience.

I think you have it exactly backwards. When you work on a project  
every day it isn't hard to remember the project structure and the  
operations you need to manipulate it. But the part-timer can't  
remember that stuff: it's extremely important to automate it.

>   I'd be an
> example of that - although I have rather enjoyed the work I did  
> about a
> year ago using gEDA, the fact is that I haven't had occasion to touch
> it since those boards got sent off.

That's when the scripts are essential. They embody the project  
structure in a way that's easy to use. It's very handy to be able to  
go back to a project you haven't touched for a couple of years, make  
a small change, type "make", and have all of the data products rebuilt.

>   Sure, I have other projects in
> mind, but they've been stuck on the back burner, and seem likely to
> stay there for some time yet.  Too many todos, too little time.

But I'm a part-timer, too. I've been using gEDA for about seven  
years, but the majority of my work over that time has been in  
spacecraft mission operations and data analysis. Electronic design is  
a sideline. But gEDA enables an individual part-timer to tackle big  
projects because it enables a high productivity approach.

>
>> People want prefabricated heavy symbols in a library, not considering
>> how massive the problem is. Too many variables. What we need is an
>> easier way to customize symbols for a particular project. And perhaps
>> better BOM post-processing support, so the user can say "I want to
>> use footprint xxx and vendor part number yyy for all 100nF X5R
>> capacitors in this project". gattrib is a nice tool for quick "touch
>> up", but not productive when you have hundreds of footprints to  
>> change.
>
> +1 about gattrib's shortcomings when there's more than a few items to
> tweak.  I would like to add that some of that seems to be a really
> weird UI - things behave oddly compared to other GUI tools, IMO.   
> OTOH,
> if there were a rich library of those heavy symbols you dislike,

I *love* heavy symbols. I have plenty. Ales calls me a heavy symbol  
advocate. But it's everything in its place. When you take into  
account all of the variables, the probability that any particular  
heavy *library* symbol will match the needs of any particular project  
approaches zero. Despite all of the talk, I predict that gEDA will  
never have a satisfactory library of heavy symbols: the job is simply  
too big.

On the other hand, when you're putting together a project, you have  
some idea of what those needs are, so that's the time to add  
"weight". And for big projects, it's handy to have a set of heavy  
symbols identified by role: "bypass_capacitor", "low_noise_opamp",  
etc. Then, as your needs change, you can change a symbol and get all  
similar parts changed automagically. Or you can import the schematic  
page into a different project built around a different parts stock  
and have it "just work".

> there'd be a lot less need for tweaking things (at least IME).

The only practical approach is to make the tweaking easier.

>   But I
> have to agree that creating a huge library like that shouldn't be part
> of gEDA's mission, especially when manufacturer's so often make this
> stuff available...  but in formats gEDA can't use.  Yeah, it's hard.
>
> The database-driven idea sounds wonderful, but my impression is that
> it's a hella bike shed - lots of talk about it but little if anything
> of general interest gets done...  or maybe everyone's waiting for one
> of the personal hacks to be just the color and glossiness they wish
> for.  And it still sounds like a lot of setup work for casual or
> occasional use.

We already have a database structure if you look more than skin deep.  
A .sym file is a fine container for relations, so a directory  
containing .sym files is a relational database. Do we really need more?

>
>> The biggest hole in the gEDA documentation concerns the scripting
>> that gschem/gnetlist can do using Scheme. There's no real API
>> documentation here, so few are aware of the latent power here, and
>> even fewer know how to harness it.
>
> +1e6 - not that Scheme is my favorite scripting language, but if there
> were a documented API it would be a viable option.
>
>> And many who find "shortcomings" in gEDA don't want a toolkit.
>
> I have very mixed feelings about that, though the above has mostly  
> come
> down on one side.  And I'm not sure I'd call it a toolkit - some of  
> the
> pieces just don't work together very well.  The mess of issues that
> arise between gschem and PCB are perhaps the most discussed, but all
> the parts I've had occasion to use feel more like a random collection
> of tools than a proper toolset - one size Phillips screwdriver, a
> couple of flat blades but none really small or really large, a hacksaw
> blade but you have to make your own frame for it...  The individual
> parts are good quality, but...

Well, of course you have to use it with other tools: gEDA only has  
the special-purpose parts of the kit. "make" may be the most  
important tool in a gEDA flow.

>
>> But I'm extremely grateful that gEDA *isn't* a massive time-wasting
>> integrated point and click thing designed for sales
>
> So am I, but I don't think that's the only kind of better-integrated
> thing that *could* be made, even if the commercial EDA toolmakers  
> don't
> have a clue about it.  :-)
>
>> I hope it stays that way.
>
> I hope gEDA can do better, so that I can curse it less next time I
> reach that stage!
>

Learn make. While intended for software development, it's effective  
whenever you generate data derived from other data (which is pretty  
much everything you do with a computer!) so long as the tools support  
a shell scripted flow. Unfortunately, describing simple tools simply  
seem to be a lost art in the 21st century. Fortunately, you can learn  
the essence from the master:

http://eprints.kfupm.edu.sa/49660/1/49660.pdf

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