X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=googlemail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
	bh=z3g3PghIrcYFPCOKlHongTUK+JcvuYZEelWkD37l80Y=;
	b=QLilaI7KzXSAi+UTZRibCOvWVKn4c4f1GgVOHw9cRTbJqq6Hj4xz+de/Vc8Y1Oq051
	K+3bFMAFrV3qLUiM/EXE4uNpZNIJSqTsL+bsfBuF1O50eY1ygUJANVBH/TA4TD8rtAJL
	bUYuG+4mxaR/kkbYf7ReWETWRIRE2f2RedB5ihcKGt/M8HAEj4/Hv3riFbQirWgOpUCC
	DBOOmIQQJ7f8iPbhr4QUSsjXOtpAFz7islC1nYiPsdj0q8BRUvZ759xDpkWME1oMI+VZ
	SqSzUQlg0EuLX8tT2GPL5YOKC9bIycccUJVX5blAZxIKV58Uhl5MIIIFSf/5ThGDpF39
	zOBA==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=z3g3PghIrcYFPCOKlHongTUK+JcvuYZEelWkD37l80Y=;
	b=sS+a0zgmuZPuULJqxq8PjK5ZncHhwloBavaxBpenpcA+odhAk8eGZHOYl38w/M37oL
	bol6euBOBzpE/DMhPZ7bTjFq/imb03w6qgtKB2qvt18PIU+0YiNkCy9F0o5NrUjoyuwt
	f59eXjeGSktV8+nG2SV3NQRgwi40ICQQj9WX6cilvW1hBG0tG/oQqjxazr4b9hTxn/Lv
	qwRRaRAJE9mdF5qXwQrpaI7tWVZ/M5JPF5ka7ioYTnjl42IbSJvL+lbbMX1KWTGuCIay
	cx3ypjHZpeFsYiDEu3gIRRpXrcnS1gCIycUeoT0693a00EeI8qwevhuJlx5OodkMUiG+
	tVVQ==
X-Gm-Message-State:	AHYfb5h4CRspsg113UV8yJ/3+X0U1j7V9btEltZZbP+ryyJYxmCqGVrb
	KRt46XANdm3nEJMarWR9ixZJwIpgpQ==
X-Received:	by 10.55.144.130 with SMTP id s124mr31221220qkd.136.1502701182711;
	Mon, 14 Aug 2017 01:59:42 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<alpine.DEB.2.00.1708140646240.27212@igor2priv>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1708140646240 DOT 27212 AT igor2priv>
From:	"Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Mon, 14 Aug 2017 09:59:42 +0100
Message-ID:	<CAJXU7q9BuoyrMLQ04sZ98NVc0rMjjUaUZ1Zb+pqn=pA3meePag@mail.gmail.com>
Subject:	Re: [geda-user] [pcb] mainline: redundant attributes: bug or feature?
To:	gEDA User Mailing List <geda-user AT delorie DOT com>
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--94eb2c0848ac32fe180556b2e23f
Content-Type: text/plain; charset="UTF-8"

Hi Igor2,

I think I agree with you that allowing multiple attributes with the same
name on a given object is a misfeature.

I didn't have involvement in developing this code, but have a recollection
that it came about around the time the new import code was written -
possibly as a part of it. When importing from schematics, attributes on
symbols get copied over to attributes on pcb footprints.

gnetlist allows (incorrectly imo), multiple attributes with the same name,
and I wonder if that might be the origin of this behaviour in pcb?

Regards,

Peter Clifton

On 14 Aug 2017 06:19, <gedau AT igor2 DOT repo DOT hu> wrote:

> Hi PCB developers,
>
> what is the policy of PCB with redundant keys in attribute lists? (Same
> key added multiple times with the same or different values.) Is this a bug
> or a feature? If feature, do you plan to keep it?
>
> I am working on a subcircuits in pcb-rnd and I want to use attributes to
> store certain values. I am asking for clarification on how pcb mainline
> plans to handle an attribute corner case in the future so that I can decide
> wether to maintain compatibility on this corner case or not.
>
> Details (pcb mainline side)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I found that the low level attribute API permits the same key to enter the
> attribute list multiple times:
>
>  - CreateNewAttribute() does this implicitly
>
>  - AttributePutToList() does this explicitly when enabled via an argument
>
> On the high level AttributePut() doesn't allow this and writing an
> existing key the second time will replace the old value. Most of the code
> uses the high level API so most of the code won't not allow multiple
> instances of the same key.
>
> I am a bit confused about what the plan was here. It seems the UI blocks
> the user from creating redundant keys, but the low level code has an
> explicit feature from it and the .pcb parser also seems to allow it by
> using CreateNewAttribute(). In the same time AttributeGetFromList() will
> return only the first match so other than preserving and displaying the
> redundant entries, the code won't be able to (easily) access them.
>
> Why I ask (pcb-rnd side)
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
> In pcb-rnd I am removing support for redundant keys.
>
> Rationale: I already upgraded the code so thate very object can have
> attributes and I am starting to use attributes from the code, e.g. refdes
> and value of a subcircuit would simply be on the attribute list. The only
> way such programmed access would make sense is if we had our keys unique.
>
> How this could affect compatibility
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> While removing it, I have two possibilities:
>
> 1. declare that it is a feature in pcb, and make some workaround (e.g.
> renaming redundant keys, like adding a /1, /2, /3 suffix), then probably
> remove the suffix on save to .pcb for proper round trip; makes sense only
> if mainline devs say it's a feature in pcb
>
> 2. declare that it is a bug in pcb and simply keep only one of the
> redundant keys (no coding required); this would slightly break
> compatibility on the very extreme case the user depended on adding
> redundant keys to a PCB, layer or element (these seem to be the only
> objects in pcb supporting attributes); or if mainline says it's a bug, and
> they fix it, we can keep 100% compatibility
>
> At the moment I favor 2., as I think 99% of pcb users don't even know
> attributes exist so they didn't intentionally add redundant keys.
>
> TIA,
>
> Igor2
>
>
>
>
>
>
>

--94eb2c0848ac32fe180556b2e23f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Hi Igor2,<div dir=3D"auto"><br></div><div dir=3D"auto">I =
think I agree with you that allowing multiple attributes with the same name=
 on a given object is a misfeature.</div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">I didn&#39;t have involvement in developing this code, but have=
 a recollection that it came about around the time the new import code was =
written - possibly as a part of it. When importing from schematics, attribu=
tes on symbols get copied over to attributes on pcb footprints.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">gnetlist allows (incorrectly imo), =
multiple attributes with the same name, and I wonder if that might be the o=
rigin of this behaviour in pcb?</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Regards,</div><div dir=3D"auto"><br></div><div dir=3D"auto">Peter=
 Clifton</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quot=
e">On 14 Aug 2017 06:19,  &lt;<a href=3D"mailto:gedau AT igor2 DOT repo DOT hu">gedau@=
igor2.repo.hu</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">Hi PCB developers,<br>
<br>
what is the policy of PCB with redundant keys in attribute lists? (Same key=
 added multiple times with the same or different values.) Is this a bug or =
a feature? If feature, do you plan to keep it?<br>
<br>
I am working on a subcircuits in pcb-rnd and I want to use attributes to st=
ore certain values. I am asking for clarification on how pcb mainline plans=
 to handle an attribute corner case in the future so that I can decide weth=
er to maintain compatibility on this corner case or not.<br>
<br>
Details (pcb mainline side)<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
I found that the low level attribute API permits the same key to enter the =
attribute list multiple times:<br>
<br>
=C2=A0- CreateNewAttribute() does this implicitly<br>
<br>
=C2=A0- AttributePutToList() does this explicitly when enabled via an argum=
ent<br>
<br>
On the high level AttributePut() doesn&#39;t allow this and writing an exis=
ting key the second time will replace the old value. Most of the code uses =
the high level API so most of the code won&#39;t not allow multiple instanc=
es of the same key.<br>
<br>
I am a bit confused about what the plan was here. It seems the UI blocks th=
e user from creating redundant keys, but the low level code has an explicit=
 feature from it and the .pcb parser also seems to allow it by using Create=
NewAttribute(). In the same time AttributeGetFromList() will return only th=
e first match so other than preserving and displaying the redundant entries=
, the code won&#39;t be able to (easily) access them.<br>
<br>
Why I ask (pcb-rnd side)<br>
~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
In pcb-rnd I am removing support for redundant keys.<br>
<br>
Rationale: I already upgraded the code so thate very object can have attrib=
utes and I am starting to use attributes from the code, e.g. refdes and val=
ue of a subcircuit would simply be on the attribute list. The only way such=
 programmed access would make sense is if we had our keys unique.<br>
<br>
How this could affect compatibility<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<wbr>~~~~~<br>
<br>
While removing it, I have two possibilities:<br>
<br>
1. declare that it is a feature in pcb, and make some workaround (e.g. rena=
ming redundant keys, like adding a /1, /2, /3 suffix), then probably remove=
 the suffix on save to .pcb for proper round trip; makes sense only if main=
line devs say it&#39;s a feature in pcb<br>
<br>
2. declare that it is a bug in pcb and simply keep only one of the redundan=
t keys (no coding required); this would slightly break compatibility on the=
 very extreme case the user depended on adding redundant keys to a PCB, lay=
er or element (these seem to be the only objects in pcb supporting attribut=
es); or if mainline says it&#39;s a bug, and they fix it, we can keep 100% =
compatibility<br>
<br>
At the moment I favor 2., as I think 99% of pcb users don&#39;t even know a=
ttributes exist so they didn&#39;t intentionally add redundant keys.<br>
<br>
TIA,<br>
<br>
Igor2<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>

--94eb2c0848ac32fe180556b2e23f--

- Raw text -