X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-TCPREMOTEIP: 207.224.51.38 X-Authenticated-UID: jpd AT noqsi DOT com Content-Type: multipart/signed; boundary="Apple-Mail=_2526618D-63E2-45DC-A37B-9F1CF2853F94"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) Subject: Re: [geda-user] pcb import schematic crash, parantheses in netname X-Pgp-Agent: GPGMail 2.5.2 From: John Doty In-Reply-To: Date: Thu, 18 Feb 2016 15:04:21 -0700 Message-Id: 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> <201602162032 DOT u1GKWL7Y005291 AT envy DOT delorie DOT com>

To: geda-user AT delorie DOT com X-Mailer: Apple Mail (2.1878.6) 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 --Apple-Mail=_2526618D-63E2-45DC-A37B-9F1CF2853F94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 18, 2016, at 2:31 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) = [via geda-user AT delorie DOT com] wrote: > On Thu, Feb 18, 2016 at 12:06 PM, John Doty wrote: >>=20 >> On Feb 18, 2016, at 12:59 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) = [via geda-user AT delorie DOT com] wrote: >>=20 >>> On Tue, Feb 16, 2016 at 11:32 AM, DJ Delorie wrote: >>>>=20 >>>>> The excuse is that doing that will lead to bugs. >>>>=20 >>>> The context was "what should gnetlist allow?" The answer is: >>>> everything it can. If the downstream tools have limits, let them >>>=20 >>> I disagree. It doesn't add much to accept weird characters. UTF-8 = is >>> full of chars that *look* identical but compare non-equal, its nuts = to >>> send them to anything except a human reader if you can avoid it. >>=20 >> It=92s a UTF-8 world, we should be part of it. But you can=92t even = avoid the problem in ASCII. 0 and O. Or 1, I, l, and |. >=20 > Yeah, we should use it for output to humans, where it makes sense. Humans read refdeses and netnames. >=20 >>>> manage those limits themselves. Why should gnetlist, or even a >>>> netlist backend, limit what *it* can handle, if it doesn't have to? >>>=20 >>> Because you *know* it's gonna break downstream stuff, >>=20 >> But you don=92t know which characters break which downstream stuff. = Should gnetlist restrict netnames to upper case for SPICE? >=20 > Yes you do. The ones that break pcb are the most important To you. > and should > be caught as early as possible by default. Restricting to upper case > would actually be fine with me as well, but it's obviously less > important because fewer people use that work flow. Tyranny of the majority? Is it even the majority? It is really ugly that = pcb users were able to adopt geda-gaf as their primary front end because = of its neutrality about the workings of the downstream, and now want to = take that neutrality away from the rest of us. >=20 >>> and fixing bugs >>> is generally cheaper the closer you detect them to where they occur. >>=20 >> You don=92t even know where the netlist is coming from. It=92s the = downstream processing=92s job to avoid breakage. If the downstream has = problems that can=92t be fixed, and the netlister is gnetlist, it may be = useful to dodge them in the back end. Gnetlist has the machinery to = support this. >=20 > What to you mean by dodge them in the back end? There=92s code in gnetlist that allows a back end to alias refdes and = netname values that violate its rules. >=20 >>> And that's the case here: the user doesn't know wtf is going on and >>> that the problem is really upstream of gnetlist. It would be better >>> to set up gnetlist st by default it pukes on weird stuff that's = going >>> to confuse downstream stuff. If user's want kanji let them set an >>> option to get it. >>=20 >> I completely disagree. The toolkit=92s job is to enable the user to = do what they need, not to get in their way. >=20 > The toolkit gets in the way most when it's inconsistent and > unpredictable, which is overall what it's being here. Consistent and predictable here means not putting arbitrary restrictions = on the user. Particularly restrictions that originate in one particular = flow out of many that gschem supports, and one particular written = language. > I remember when > I first encountered this issue myself and it was confusing and > annoying that gschem couldn't tell me up front which chars were going > to be a problem. You have freedom to choose your flow here. The cost of that freedom is = that you have to understand the choices you=92re making. >=20 >>>> If I change the pcbfwd netlister to fail on '$' for some then-valid >>>> reason in pcb, and pcb itself changes to allow '$', I have to go = back >>>> and "fix" the netlister (and possibly older but previously = installed >>>=20 >>> So what? In the meantime you haven't confused the heck out of users >>> for no real gain. >>=20 >> You don=92t know what other users need, so you can=92t say =93no real = gain=94. No real gain for you, maybe. >=20 > What ~90% of users need is for pcb to work as well as possible. A guess without real data. But regardless, that=92s the "tyranny of the = majority=94. It=92s not acceptable that pcb users wish to take away the = freedom of the rest of us. Pcb=92s problems need to be solved either on = pcb=92s side of the interface, or by exploiting geda-gaf=92s support for = scripted optional features. > I > know you don't like that, but you've implicitly acknowledged it > yourself with your complaints that development is pcb-centric. So the > real gain is for ~90% of the users, not just me The default behavior > of the toolkit should favor that 90%. No, it should favor freedom. What you want to do isn=92t merely = pcb-centrict, it=92s also English-centric. > It's trivial for you to set an > option that relaxes a restriction on the available character set. The toolkit is designed to allow you to script whatever restrictions = your flow requires. If you want to do that, go ahead. But don=92t shove = it down other user=92s throats. > You > can even advise the user of the possibility when funny characters are > seen. It's much less trivial for a relatively new user to sort out > what's going on in cases like this. >=20 > Britton >=20 >=20 John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ jpd AT noqsi DOT com --Apple-Mail=_2526618D-63E2-45DC-A37B-9F1CF2853F94 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWxj/lAAoJEF1Aj/0UKykRNSEP+wU2wFZjOoLVRQAcePP4Ain4 QiOX4XbHbWu8WBEJY5OcZqeIoM9hfcxWVfJlQ26Jk0C+KvdyXv8Sywmg5G8E79RL UYrs0WvEIFPLzqq64V+eaXb/zEPZx5CljoPQhyU1PUp+Nh2Zt1AgbDscOZ3NkUmb rNNQCyAuhqu30HZW2yvehimh+NwW03Fx8tDrDhjKlaexKhmJ8+FkRAZfMRL69VR6 Ijise4U4Q4N787Ci4+B2KzpCxBwOBV8y+S8Fu6a9+WI1r0QxqJdgBI48anJRTZP8 tBYHAWgtXcvc27lioJSiDJFl7gbaMubnicGpv07Pwt4B7OXcI58oBd4NMFJfuBaB 5yXWoYlrYaKPfS6k37QJGR+jnXOk7CjtIK4+TrcnyevdaNRN9L8CGYxeMfhrGKvW 6BuBREtLaF953jpU4BMBm/KVO1IuvZFNCWHU4J7f937FY+77e3oo6xIA56qrTHym rzJGmqF3ozXJ39aT3spn9Qk4F8P7Jkjg/wBHRvV4B6AISsZA2c1K1Tk5C7RNvXkb RkV6TSUiawUWKBHfH6z8xGLNl5briKq1eMk8rV/hkPODUvthzXKU00EH20Zkk5hc YhRXLgUVCFJQgrtrovtBa+A/iSUD0QOhycjZND485/Jsujg876H0m3RPZ7yFMUtv 9iySpbYosh/hd5J95+V2 =azW9 -----END PGP SIGNATURE----- --Apple-Mail=_2526618D-63E2-45DC-A37B-9F1CF2853F94--