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=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=kRIaB4KwoinMRy9LxGkVs2/NSb5nn994lxEdjFX3Pxc=; b=bbMcAmnjMHCujpcTzwoBPnjCwXU5BGcXkxO2MD1uDhSu3U8l2DgX3d4k2aVtakmbuC bFAnal/cSYQ05FTPFp9+BVHFgQOKhoFZxDjDa7euh0H+xEFpvYG1OphmFDVCtoQ4Pzn6 HFK0U8PwFueb2XRBZGn2q+7Q4p7YbTbFzlG6OG2zSxe3urjvoxYl2nDbXLe1VFphYlKV kQH0bzPEpqS67RrklfERXzG5jkeGWqXjMky89DSSmNGb77QRYjQq2gO0JRwZi77j6J7X tfO+jt+yYqGN2+TJ6O40GDN/Eakk/uZLBJYvmx/KFhYuk9AAGj1w/n8LMW6SzbBN1zLp 0WZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=kRIaB4KwoinMRy9LxGkVs2/NSb5nn994lxEdjFX3Pxc=; b=CQKjTsDF5Lj5YAd43fsfSItNUDFU2rKiutiR1xj/kHqGBXSyYKIhRu7PHjIC1ZrCvs BpJw3R3RZbW+94SWV59Ggvuo/jHNXFDooBUNT2IScQh07zyCgsyU0IZz7AE364sqLmgj mfH2Yh0j5ULOrnjDl+WnyG8PYgdu68SanPyunKG72Yq6cqUr7oSLfyzOgftzSNXRHFun Z4a/1yRjTvRS/eFmrR47sbCctQciZvuC+0pbdBk0dz0taREW7sRP3gQy4pDgk/EOwgC2 JWlMhldI4/C3EDCbO4fdt168YX49192Qw5muHTCwgsL3IfAjE9TVfz+VA2+ga5yLzfJ9 w3Xg== X-Gm-Message-State: AG10YOQB+9GKLiNnM4HJCF39LSFyfYiWuOYcVCL7snkgkMJQyZx4Yd/tY36HkpdBYpEZHtJIJwYanYcjTZqLeg== MIME-Version: 1.0 X-Received: by 10.202.199.10 with SMTP id x10mr17792447oif.101.1455647562104; Tue, 16 Feb 2016 10:32:42 -0800 (PST) In-Reply-To: <201602161814.u1GIE4N8030809@envy.delorie.com> References: <20160215215221 DOT fd472794e7b9446a243bfc40 AT gmail DOT com> <201602152055 DOT u1FKtM4K011038 AT envy DOT delorie DOT com> <20160215220938 DOT bbc7eaa59d827cd0b261ea97 AT gmail DOT com> <201602152135 DOT u1FLZrw9012774 AT envy DOT delorie DOT com> <7F210DE7-0A0B-42F9-ABBE-2C2768621186 AT noqsi DOT com> <20160216081722 DOT 1065cbed6653d3da4ffc7498 AT gmail DOT com> <201602160724 DOT u1G7Ox26001785 AT envy DOT delorie DOT com> <20160216085628 DOT b70143c330cd4da98a4603d3 AT gmail DOT com> <201602160805 DOT u1G85d8c003148 AT envy DOT delorie DOT com> <20160216092912 DOT 7f7439f703b49175a21dbb1b AT gmail DOT com> <201602161715 DOT u1GHFMBB028078 AT envy DOT delorie DOT com> <201602161814 DOT u1GIE4N8030809 AT envy DOT delorie DOT com> Date: Tue, 16 Feb 2016 18:32:42 +0000 Message-ID: Subject: Re: [geda-user] pcb import schematic crash, parantheses in netname From: "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=001a1134f8b0db8d17052be75b1e 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 Precedence: bulk --001a1134f8b0db8d17052be75b1e Content-Type: text/plain; charset=UTF-8 Unless I misread, gnetlist is just fine.. it was PCB's import feature which failed. The gnet-pcbfwd.scm back-end appears not to be escaping any strings it forms PCB action strings with - which means either it needs to restrict the strings to the subset which won't trip up the action parser, or we need to add quoting + escaping to our gnetlist backend, and the appropriate unquoting / decoding to PCB. Bonus points if the quoting / escaping scheme is standard w.r.t. other programs / common usage. g_strescape might be usable, (unencode with g_strcompress), but I still question the wisdom of allowing arbitrary stuff like whitespace, tabs, newlines etc.. inside netnames. Doing so almost guarantees interoperability problems with other programs - but perhaps that is just a question of allowing the user the option of shooting themselves in the foot. Peter On 16 February 2016 at 18:14, DJ Delorie wrote: > > > On the other hand, we already use "/" for discerning hierarchy, so that > > already implies a certain restriction of legal characters within a > net-name > > portion. I'm sure we may also run into problems with our existing format, > > with "-", where "-" is present in the net-name, and/or pin-name. (U1-1, > > U2-2 etc..) > > You're talking about "what are legal characters for refdes's and > netnames" but I'm talking about "what characters should gnetlist be > able to handle properly". At the level of "what strings get passed > through without gnetlist crashing" it should be UTF-8. > > Sure there are syntax-related characters like / and - but those aren't > problems *for gnetlist* as long as it passes them downstream > correctly. > > If we decide we want to allow characters like / and - in netnames, > refdes's, and whatnot, then we need to come up with a way for those > names to be communicated between gschem and downstream without > corruption or confusion - assuming downstream has a way of doing so. > gsch2pcb uses '-' between refdes and pin, but File->Import doesn't, > for example, so if we want to allow '-' in a netname, either gsch2pcb > needs to be prepared to see two '-'s or we have to deprecate it in > favor of File->Import. > --001a1134f8b0db8d17052be75b1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unless I misread, gnetlist is just fine.. it was= PCB's import feature which failed.

The gnet-pcbfwd.scm ba= ck-end appears not to be escaping any strings it forms PCB action strings w= ith - which means either it needs to restrict the strings to the subset whi= ch won't trip up the action parser, or we need to add quoting + escapin= g to our gnetlist backend, and the appropriate unquoting / decoding to PCB.=

Bonus points if the quoting / escaping scheme is standar= d w.r.t. other programs / common usage.

g_strescape might= be usable, (unencode with g_strcompress), but I still question the wisdom = of allowing arbitrary stuff like whitespace, tabs, newlines etc.. inside ne= tnames. Doing so almost guarantees interoperability problems with other pro= grams - but perhaps that is just a question of allowing the user the option= of shooting themselves in the foot.

Peter

On 16 February 2= 016 at 18:14, DJ Delorie <dj AT delorie DOT com> wrote:

> On the other hand, we already use "/" for discerning hierarc= hy, so that
> already implies a certain restriction of legal characters within a net= -name
> portion. I'm sure we may also run into problems with our existing = format,
> with "-", where "-" is present in the net-name, an= d/or pin-name. (U1-1,
> U2-2 etc..)

You're talking about "what are legal characters for refdes&= #39;s and
netnames" but I'm talking about "what characters should gnetl= ist be
able to handle properly".=C2=A0 At the level of "what strings get= passed
through without gnetlist crashing" it should be UTF-8.

Sure there are syntax-related characters like / and - but those aren't<= br> problems *for gnetlist* as long as it passes them downstream
correctly.

If we decide we want to allow characters like / and - in netnames,
refdes's, and whatnot, then we need to come up with a way for those
names to be communicated between gschem and downstream without
corruption or confusion - assuming downstream has a way of doing so.
gsch2pcb uses '-' between refdes and pin, but File->Import doesn= 't,
for example, so if we want to allow '-' in a netname, either gsch2p= cb
needs to be prepared to see two '-'s or we have to deprecate it in<= br> favor of File->Import.

--001a1134f8b0db8d17052be75b1e--