| delorie.com/archives/browse.cgi | search |
| 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> | |
| <D3167F4D-4750-49F8-9125-BDC4937F5C69 AT noqsi 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> | |
| <CAJXU7q_w5NunkojiCr36RHRTq0hJ+PZP1e0GumTRMoGXcvgRXQ AT mail DOT gmail DOT com> | |
| <201602161715 DOT u1GHFMBB028078 AT envy DOT delorie DOT com> | |
| <CAJXU7q9d9VqBmqabKfE3M3banZ8jn2c3LaWxBSK9_YCm9XN3_w AT mail DOT gmail DOT com> | |
| <201602161814 DOT u1GIE4N8030809 AT envy DOT delorie DOT com> | |
| Date: | Tue, 16 Feb 2016 18:32:42 +0000 |
| Message-ID: | <CAJXU7q_wm_jqACf6ycg4bVRPRKx53xUKq9iGCLhP=k-C_LjepA@mail.gmail.com> |
| 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]" <geda-user AT delorie DOT com> |
| 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 |
--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 <dj AT delorie DOT com> 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 <div dir=3D"ltr"><div><div>Unless I misread, gnetlist is just fine.. it was= PCB's import feature which failed.<br><br></div>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.= <br><br></div><div>Bonus points if the quoting / escaping scheme is standar= d w.r.t. other programs / common usage.<br><br></div><div>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.<br></div><div><br>Peter<br></div></div= ><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 16 February 2= 016 at 18:14, DJ Delorie <span dir=3D"ltr"><<a href=3D"mailto:dj AT delorie= .com" target=3D"_blank">dj AT delorie DOT com</a>></span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"><span class=3D""><br> > On the other hand, we already use "/" for discerning hierarc= hy, so that<br> > already implies a certain restriction of legal characters within a net= -name<br> > portion. I'm sure we may also run into problems with our existing = format,<br> > with "-", where "-" is present in the net-name, an= d/or pin-name. (U1-1,<br> > U2-2 etc..)<br> <br> </span>You're talking about "what are legal characters for refdes&= #39;s and<br> netnames" but I'm talking about "what characters should gnetl= ist be<br> able to handle properly".=C2=A0 At the level of "what strings get= passed<br> through without gnetlist crashing" it should be UTF-8.<br> <br> Sure there are syntax-related characters like / and - but those aren't<= br> problems *for gnetlist* as long as it passes them downstream<br> correctly.<br> <br> If we decide we want to allow characters like / and - in netnames,<br> refdes's, and whatnot, then we need to come up with a way for those<br> names to be communicated between gschem and downstream without<br> corruption or confusion - assuming downstream has a way of doing so.<br> gsch2pcb uses '-' between refdes and pin, but File->Import doesn= 't,<br> for example, so if we want to allow '-' in a netname, either gsch2p= cb<br> needs to be prepared to see two '-'s or we have to deprecate it in<= br> favor of File->Import.<br> </blockquote></div><br></div> --001a1134f8b0db8d17052be75b1e--
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |