On May 31, 2011, at 11:02 PM, Peter Brett wrote: The attached script not only emits a message, but substitutes
"attribute_conflict" for the attribute in question. Since that's not normally a legitimate value, it should help the user to detect the problem. From my perspective, I don't understand why this is better. 1.7.0 warns about undefined behaviour, In a scripted flow for a large project, warnings like this tend to get lost in all of the other chatter. and defaults to backwards-compatibility (which makes some sense IMHO). No, that behavior is very troublesome. The old behavior is to use the first attribute from the first symbol in the package. But that's quite confusing: in general, the user has no easy way to know or control which symbol is first. This script deliberately poisons the netlist. Exactly. This is consistent with other gnetlist behavior. If no attribute is found, the resulting value is "unknown". So, I think "attribute_conflict" makes sense when there's a conflict. In my ideal world (haha) gnetlist would generate errors on attribute conflicts. :-) What kind of error do you want? gnetlist -m censor_fix.scm (other gnetlist args) For the benefit of those who share your preference for this behaviour: does loading this scm file from a configuration file work? :-) No, because it works by redefining (unique-attribute). That's defined in gnetlist.scm, which is loaded after the configuration files. It wouldn't be hard to set up a mechanism where a configuration file could create a list of deferred actions, to be performed when gnetlist-post.scm is loaded. That would allow this redefinition to be specified in a configuration file, but performed at the right time. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user