On Jan 5, 2011, at 3:19 PM, Peter TB Brett wrote: > On Wednesday 05 January 2011 19:04:37 John Doty wrote: >> On Jan 5, 2011, at 11:49 AM, Peter TB Brett wrote: >>> On Wednesday 05 January 2011 18:38:04 John Doty wrote: >>>> They're not especially bad. In that project "make clean; make" generates >>>> 2074 lines of chatter, only about 1/3 of them from gschem and gnetlist. >>>> The worst offender is pdflatex. >>>> >>>> You can see how a warning could easily be lost. >>> >>> That doesn't make it okay to deliberately break designs which currently >>> work, even if you don't think they deserve to. ;-) >> >> Is there any evidence that there are any? In any case, in other areas of >> computing it is considered OK for behavior to change between versions of a >> tool for cases when the input is ambiguous. It's not like changing the >> default attribute promotion policy: that wasn't ambiguous. > > No, but there wasn't any evidence that that would actually break users either.
You didn't ask me ;-) It was expectable that changing attribute promotion would break things. It changed a predictable, well known behavior. On the other hand, when multiple attributes are present but the back end only expects one, the "pick the first one" behavior is only predictable to experts (and might reasonably change with gschem revision). Cut a component out, paste it back in at the *same place*, and you might get a different footprint in the BOM or netlist the way it works now. This isn't a theoretical problem: it has bitten both Kai-Martin and me, and most likely others who haven't complained. > > Now, I would *very much* like to see this ambiguosity cleared up, but as part > of a holistic strategy to make attributes clearer and easier to process in an > automated and deterministic manner. It's a computer. It's deterministic. It just isn't predictable. These are different concepts, grumbles the physicist. Please use the right word. > > 1) Decide if we wish to continue to allow multiple values for the same > attribute in the same context (c.f. 'net=' vs 'refdes=" behaviour in previous > discussion), and document this. > > 2) Decide which (if any) attributes should be "reserved" for the > implementation, i.e. have their semantics strictly prescribed rather than > being "free-form", and document this. For example, we may wish to prescribe > the merging behaviour of 'refdes=', but also add an 'id=' attribute that if > present on a symbol *must* be unique within design. > > 3) Determine which (if any) widely-used attributes can no longer work in the > same way as a result of the previous decisions, fully document the changes, > and create an automated tool to find problems in existing designs and > automatically update them. > > If we are *not* going to be backwards compatible, we should actually try and > do some *design* and come up with an approach that's both well-documented and > reasonably future-proof. A better approach to attributes is needed, but this bug fix should not be a hostage. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
