Mail Archives: geda-user/2021/09/26/13:44:32
Roland Lutz:
...
> I'm not terribly opposed to supporting empty (as opposed to, unset)
> attributes, but having gEDA treat "refdes=" as an empty attribute would
> introduce a semantic change as text objects in existing schematics may
> then suddenly be interpreted as attributes.
$ grep -B1 'refdes=$' top.sch
T 17000 9439 5 10 1 0 0 3 1
refdes=
$
In lepton, an empty refdes, gives me an error:
ERROR: Throw to key `attribute-format' with args `("%parse-attrib" "~A is not a valid attribute: invalid string '~A'." (#<geda-object 0xcd3b40ab80> "refdes=") ())'.
While gsch2pcb seem to treat it as nonexistant (or as text) and
uses the default refdes. Using the default refdes is confusing,
I tend to prefer to have an error message in this case,
or rather to accept it as empty.
$ cat top.net
U?/unnamed_net4 U?R2-2 U?R1-2
unnamed_net2 U?R2-1 R3-1
unnamed_net1 U?R1-1 R3-2
My guess is that, currently, for refdes specifically, none will use
T ... 1
refdes=
intentionally, beceause if they do, the'll get the annoying U? refdes
which they don't know where it come from since it isn't in the
schematics. So users are already burned on that thing.
For other attributes not in the master list, don't they just behave as
text in the schemtics so there wouldn't be a change there.
Lepton seems to treat all sinle line things like "something=" as
invalid attributes, so we can ask them how that has played out.
I don't have a whole lot of sch file from others to check on, but
my guess is that the current use is non-existant.
It should be safe to allow attributes with empty value.
> I've long been in favor of making text and attributes different kinds of
> objects, which would remove this ambiguity. But that (like many other
> potential improvements) would mean an incompatible file format change,
> which I have so far tried to avoid.
Why don't we (geda lepton and other writing programs related to the
file format) then sit down and do that.
The format as is isn't too bad, but there are corner cases that needs
to be resolved, like the case when we have multiple footprints files
with the same name.
> Allowing component objects to have an empty refdes would be another,
> different change. What would it mean for a component to have an empty
> refdes? If the empty string was treated like any other value, all such
> components would be merged into one package. Is this useful behavior?
Why not let the user decide, instead of having special cases and rules.
I believe it would be useful for designs with subsheets.
If someone wants to use it on regular symbols, it's their pain.
> I'm playing with the thought of allowing components to not have any
> refdes= attribute at all in situations where this makes semantic sense,
> e.g., with cascade simulation. This is a somewhat different concept,
> though, and may not play well together with hierarchy.
Not done that so I can't provide insights on thoose simulations.
Regards,
/Karl Hammar
- Raw text -