[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Fixing the attribute censorship bug

   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


     From my perspective, I don't understand why this is better.  1.7.0

     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


   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

     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.

geda-user mailing list