Re: gEDA: SUMMARY of "possible change, feedback desired"

[Magnus Danielson <cfmd@swipnet.se>]

From: Ales Hvezda <ahvezda@seul.org>
Subject: Re: gEDA: SUMMARY of "possible change, feedback desired"
Date: Thu, 26 Jul 2001 22:34:00 -0400

> Hi All,
> 
> 	I'm going to be lazy and respond to all the posts on this subject
> with one long message.  Forgive my hacking.
> 
> 
> Steve Tell wrote:
> >... All I can think of is a fairly radical change: make the parsing
> >stateless by assigning a unique identifier to symbol-instances and nets
> 
> 
> 	Yeah, I like that.  I really want to make the format _completely_
> stateless.  So, things like attributes, text objects, and the eventually
> multiline text object will have to be represented slightly differently.
> The only thing which can't be stateless is embedded components.  I'll
> have to think about that a bit.  Ideas?

I think going completely stateless is to overdo it to some degree.
I think that some minor state is acceptable, as long as you don't have
to fight the big ugly dragon (featured on the "Dragon book" -
"Compilers - Principles, Techniques, and Tools" by Aho, Sethi and
Ullman).

I would be interested to hear your reasoning for being _completely_
stateless. My point is, keeping it down is good, but if you run into
trouble or excessive rewrites of critical code for a fairly low gain
(except for the principal reason of doing things "right", whatever
that is), why do it?

> >when they are placed.  Then, attribute entries get associated with a
> >symbol or net not by their nearby position in the file, but by having
> >the matching ID.
> [snip]
> >
> >Consider a component instance with unique instance-12345 and two attached
> >attributes:
> >C I$12345 43200 59000 1 90 0 capacitor-1.sym
> >T I$12345 43200 59000 5 10 1 1 0 0 uref=c1
> >T I$12345 43300 59400 5 10 1 1 0 0 value=20f
> >
> >Unique IDs for instances and nets makes back-annotation much cleaner.
> >(This idea I first saw in the mentor graphics tools - they have unique IDs
> >for component instances, net line segments, net vertices, and text items.)
> 
> 
> 	The idea that all objects (including text items) get an instance
> number has been a change I have been wanting to make (probably to the
> existing gaf as well).	However, what you suggest is also really good, use
> that instance number as a way of associating items with each other (that's
> all an attribute is), so a slight modification to your above example:
> 
> component I$12345 43200 59000 1 90 0 capacitor-1.sym
> text I$12346 43200 59000 5 10 1 1 0 0 uref=c1
> text I$12347 43300 59400 5 10 1 1 0 0 value=20f
> associate I$12346 with I$12345
> associate I$12347 with I$12345
> 
> Something like that anyways.  Expanding the T's and C's to full names is
> a good idea too, see below.  Also, putting the text on the same line is a
> good idea too.  I also want to get rid of the restriction that attributes
> can only be text items (started down that direction in the beginning,
> but later changed my mind).

Is there a way to drop the $ signs in that? If there is a simple thing
to drop, I at least would like to avoid them. Just think how confusing
excaping can be in scripting and the like when doing a quickie the
UNIX way. I.E. try to avoid non-alphanumeric characters as much as
possible.

> >Most all of the commercial schematic tools I know of use an opaque binary
> >format that simply doesn't work at all well with in a multi-designer
> >environment that wants to use good software configuration-management
> >practices.
> 
> 
> 	*NO* binary formats.  See: http://www.geda.seul.org/FAQ.html#E6
> Certainly not as the native format.  I don't care what else people
> want to read in (from a database, from the web etc...), but the native
> formats all stay ASCII.  I like the idea about being able to merge changes
> using RCS/CVS etc...  With everything on one line, it is possible to
> do this.

Indeed. I like the idea of an EDA tool being CVS complaint without
having to put a big brown paperbag over the glue-hacks.

> >on-XML: 
> >Big "talky" files that will be hard to parse with simple
> >sed/awk/perl/whatever scripts. I think the word I'm looking for is:
> >current format is stateless (expect for {} maybe), XML isn't.
> 
> 
> 	IIRC, Oregano uses compress XML files as it's file format.
> Need to look at that.  Yes, XML is as far from stateless as you can
> get. :-|

Indeed. You actually can get worse, but that is beside the point.

> Magnus wrote:
> >First comment: It would not hurt to change the initial letter into a
> >keyword. This would have the benefit of ease the human reading (when
> >necessary) as well make it easier to find a suitable designation for
> >something when one extends the format. The actual parsing does not
> >become that much more complex and I think the gain would be fair.
> 
> 	Agreed, bus is far better then U or circle is better than V etc...

Right. Just imagine what happends as you get more than 26 things to identify!

> >Indeed, there is something that I support (especially since the
> >industry is moving to metrics, some american IC manufactors only gives
> >measures in mm these days).
> 
> 
> 	Also, it seems that it is important to be able to specify or
> represent different units in the same file.  Somebody was complaining
> about that on sci.electronics.cad about some other EDA system not
> being able to do that.  Units are critical especially in PCB.  

Indeed. For instance, you get some measures in mils, some in inches,
some in milimeters and yeat some in American inch (which is just a
teeny wheeny of the international inch).

> 	Speaking of units, I also want to be able to easily change
> the precision of the internal representation of points, ie, nanometers
> vs mils vs millimeters.  There is no easy way of doing that with gaf.

You can't do nanometers. Americans seems not to know this unit. Just
look at the chip industry, they talk about 0.25 um, 0.18 um and 0.13
um when they should be talking about 250 nm, 180 nm and 130 nm
respectively. Sigh.

Sorry, this was just my general frustration on the issue.

But yes, you are right. One thing to note both km, dm, cm, mm, um and nm
are not actual units, they are there meter unit with different
prefixes. Maybe this is something to consider?

Hmm. What if someone wants to measure distance in ns or parsecs?
Just toss them in!

Make the method generic, let the user interface give the standard
variants. It might be necessary for us to ensure that when a new
measure is being introduced, its relation to the others are
established so that the joint usage doesn't make us confuse the hell
out of things (like making an SMA in the size of a truck or something,
can be a bit tricky to get the PCB manufactured).

Oh, Ales... waaay back in time I sent you a bunch of emails. Please
have a look at those... some of they probably applies to some degree
to the whole file format issue (and not to the unit discussion).

> >But then it is as simple as writing a backend to gnetlist to be able to
> >>read an other format, standard or not. You could even read current format.
> 
> 	Certainly an interesting idea, a custom format which is read in
> using a scheme script.  Should be very possible with the above mentioned
> mechanism.

I'd like gnetlist under gschem control one way or another. The import
and export of netlists should be shown up-front. It is not only me
being lazy, it is also an educational aspect for newbies, especially
for those not being into doing it "The UNIX way".

> >Maybe that's what you thought about but not going the complete way to
> >saving in scheme too? I assume you will continue to use scheme? Anyhow, my
> >suggestion...
> 
> 	Actually, I think I will drop scheme and use Visual Basic, seem to be
> popular nowadays.

AAARRRGGGHHHHH!!!!!!!!

> 	hehe, just kidding of course.

Phew...  ;O)

>  Yeah, scheme (yes, parenthesis,
> ())((()))())) :) is here to stay.  I like guile, but the fact that it
> probably won't be easy to create a native port for win32 is a minor issue.
> I should spend some time and see how hard it really is to build guile
> with mingw or --no-cygwin.  I think everybody is now used to guile,
> so changing that will be hard (and a stupid idea).  gnetlist is a
> prime example of a scheme enabled program done right:  1) a reasonable
> stable api exported to scheme and 2) I only had to write one backend. :-)
> 
> 	I am looking at using something like swig (www.swig.org) to
> generate the interface functions between guile and the rest.  It might
> be even possible to generate bindings for python, tcl, etc... (whatever
> else swig supports).  Is this of value to people?  I don't know
> if I want to go down this path, because it would then force people to
> have everything (python, guile, tcl, perl, etc...) installed, especially
> if we get a python camp and a perl camp, etc... Maybe I'm just imagining
> all this.

While in one end I don't mind an open system allowing for many
interfaces I in the other end think you should not open up this
pandora box (or box of worms, whichever is the scariest).
If people start to contribute scripts and even depend on scripts in an
ever growing flora of languagues, then we have lost for real. It will
be a headache to understand for the casual programer and even less to
maintain.

Cheers,
Magnus - I'm casual allright...