Re: gEDA-user: gEDA just hit SlashDotOrg

[John Doty <jpd@xxxxxxxxx>]

On Aug 10, 2009, at 7:27 PM, Kai-Martin Knaak wrote:

> On Sun, 09 Aug 2009 17:57:37 -0600, John Doty wrote:
>
>>> This is not conversion, but a work flow partially in geda,  
>>> partially in
>>> some other suite. As nice as it is,
>>
>> Name another tool that can do this as easily and flexibly as gEDA.
>
> emacs

Well, you can compose your netlists in emacs if you want. I'll keep  
using gnetlist ;-)

>
>>
>> If we take gEDA's strengths for granted, we will lose them.
>
> Its hard to stay on topic, is it?

Understand that this is precisely the topic to me. I don't believe,  
Kai-Martin, that you appreciate what a powerful tool Ales has given us.

>
>>> it does not make the switch to and
>>> from geda any easier. The missing feature is the ability to  
>>> import and
>>> export symbols, schematics, footprints and layouts to and from other
>>> suites.
>>
>> So we need even greater flexibility. Less hard-wired, fewer  
>> barriers to
>> arbitrary transformations.
>
> No, we need import and export mechanisms that work. Right now,  
> there is
> none. Lack of features is the opposite of flexibility.

Wrong. Ever use the language PL/I? Loaded with every feature the best  
computer scientists IBM could find asked for. Touted as the universal  
language. Displaced by the much simpler C language (to the extent  
that a universal language makes sense). I'm an old PL/I programmer  
(learned it 40 years ago, yikes). Believe me, C is much more flexible  
and easy to use. All those features just got in the way.

Ever use the Viewlogic EDA suite? I have. gEDA is very similar, but  
has many fewer features. Hurray! Again, that makes gEDA more flexible  
and easier to use, especially if your needs are a bit eccentric. And  
in the Viewlogic case, lots of features led to lots of bugs.

>

In the case of export, the basic problem is that the features are in  
the wrong place. The gnetlist front end provides hard wired features  
that instead belong in the convenience functions in gnetlist.scm. If  
the front end stuck to parsing files on request from the back end and/ 
or the convenience functions, the back end could see all of the data  
if it needed, and transformations to formats other than flat netlists  
and BOM's would be possible.

Import is a different problem. Parsing a complex input format is  
trickier than outputting it, especially when it's undocumented.  
There's probably no general framework that makes sense here: it'll  
require separate tools. In a sense, it's like those gnetlist back  
ends: the tools will mainly be written by those who want to do the  
importing. But it's an order of magnitude harder. My old Viewlogic  
schematics aren't relevant enough to today's jobs to make it  
worthwhile for me to tackle this.

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