Re: gEDA-user: Make-sure-internal-order-of-symbols-is-not-relevant-.patch

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

I am not allowed to write to geda-devel, so my reply to Peter Brett goes 
here:

On Fri, 31 Jul 2009 07:02:42 +0100, Peter TB Brett wrote:

>> a) Use g_cmpstr0 to compare individual strings, so NULL is handled
>> gracefully. It is assumed to be the the lowest value possible.
>>
>> b) use all relevant information potentially available in a component
>> block in the *.sch file.
>>
>> c) do a hierarchical sort. If objects prove the same for a high
>> priority property, sort them according a lower level property.
>
>> d) The hierarchy of properties to be sorted against should be such that
>> the resulting order appears intuitive to humans. Sorting order should
>> reflect the natural hierarchy of objects.
>
> How do you know which attributes are "higher" or "lower" level
> priorities (apart from the obvious "refdes=" at the highest level)?

There is a hard coded list of attributes that is tested first. Then comes 
a list of attributes found in the schematics fed to gnetlist. This 
secondary list of attributes itself is sorted according to attribute name.


>> e) (corollary of d) There are a number of predefined attributes. These
>> should be sorted first. However, there may be attributes not known in
>> advance. These have to be taken into account too.
>
> What do you mean by "predefined attributes" in this context?

A subset of the "master attribute list". Attributes like pintype, 
graphical, or symversion should not receive high priority during the sort.


>> 1) refdes
>> 2) footprint
>> 3) value
>> 4) slot
>> 5) symbol name
>> 6) The value of any other attribute sorted by attribute name
>> 7) x coordinate of the symbol
>> 8) y coordinate of the symbol
>
> There are several backends and workflows which *may not use* "footprint"
> or "value".  Wouldn't it be better to (a) just use all available
> attributes in alphabetical order for sorting,

I don't see, why a completely alphabetically sorted list of priorities is 
any better to these back-ends than any other order. On the other hand, 
sorting for footprint and then value makes sense for humans -- simply, 
because these attributes are defined in the vast majority of cases. This 
is a tribute toward goal d) mentioned above.


> or (b) provide some
> mechanism for the backend to tell the frontend which attributes it cares
> about?

I don't think, that any information should flow from back-end to front-
end. Sounds like asking for trouble to me.


>> ( ... two resistors, same refdes, same value, no other attribute ... )
>>
>> gnetlist back-ends should not care for purely graphical differences. So
>> the gnetlist front-end doesn't have to either. It may sort the
>> components according to coordinates, anyway.
>
> You missed my point that the gnetlist frontend *doesn't know* which
> attributes the backend considers to be "purely graphical".

I should have been more clearly on that. *All* attributes of a symbol 
should be included in the sort. It is the other properties implied by the 
placement of attributes, their color, or visibility, that no decent back-
end should care about.


> My suggestion is to sort first by attributes that *directly* affect the
> results of gnetlist's frontend (e.g. "refdes"... not sure about any
> oters), and then by *all* other attributes in ascending alphabetical
> order of name.

Seems, we are pretty close :-)


> What you do if two symbol instanciations still match at this point is
> still open for debate, too...

Nothing.
At this point, all information a back-end should ever care about, was 
included in the sort. If all of them match, they are considered equal, 
and it's the back-ends job to deal with that pair of cloned symbols. 
Since they are guaranteed to be successors in the internal list of 
components, it is trivial for the back-end to check for this case.
The front-end might issue a warning in the logs for convenience.


> don't forget that symbols may come from
> different schematic pages. Is the order of symbols allowed to change if
> you move a subcircuit from one schematic page to another?

Is the information which sheet a symbol comes from available to the back-
end? If so, this information should be included in the sort. I'd say, as 
a last resort after all attributes match. For this to work, the list of 
sheets has to be sorted, just like the list of attributes. I'd take their 
full path name as sorting criterion. This is guaranteed to be unique and 
is intuitive to humans, too.

---<(kaimartin)>---
-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53




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