Mail Archives: geda-user/2016/02/18/17:04:43
--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] <geda-user AT delorie DOT com> wrote:
> On Thu, Feb 18, 2016 at 12:06 PM, John Doty <jpd AT noqsi DOT com> 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] <geda-user AT delorie DOT com> wrote:
>>=20
>>> On Tue, Feb 16, 2016 at 11:32 AM, DJ Delorie <dj AT delorie DOT com> 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--
- Raw text -