Mail Archives: geda-user/2016/02/21/23:55:02
On Thu, Feb 18, 2016 at 1:04 PM, John Doty <jpd AT noqsi DOT com> wrote:
>
> 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:
>>>
>>> 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:
>>>
>>>> On Tue, Feb 16, 2016 at 11:32 AM, DJ Delorie <dj AT delorie DOT com> wrote:
>>>>>
>>>>>> The excuse is that doing that will lead to bugs.
>>>>>
>>>>> The context was "what should gnetlist allow?" The answer is:
>>>>> everything it can. If the downstream tools have limits, let them
>>>>
>>>> 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.
>>>
>>> It’s a UTF-8 world, we should be part of it. But you can’t even avoid the problem in ASCII. 0 and O. Or 1, I, l, and |.
>>
>> Yeah, we should use it for output to humans, where it makes sense.
>
> Humans read refdeses and netnames.
So do a lot of other things, and you can see the results for this
poster, and he's not alone
>>>>> manage those limits themselves. Why should gnetlist, or even a
>>>>> netlist backend, limit what *it* can handle, if it doesn't have to?
>>>>
>>>> Because you *know* it's gonna break downstream stuff,
>>>
>>> But you don’t know which characters break which downstream stuff. Should gnetlist restrict netnames to upper case for SPICE?
>>
>> 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.
Nope, no one wants to take it away. They want defaults that make the
toolkit work reasonably out of the box. This is actually very much in
your interest as well since it will help gschem stay viable long-term,
since pcb does have most of the users and probably also most of the
potential to attract new users.
>>>> and fixing bugs
>>>> is generally cheaper the closer you detect them to where they occur.
>>>
>>> You don’t even know where the netlist is coming from. It’s the downstream processing’s job to avoid breakage. If the downstream has problems that can’t 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.
>>
>> What to you mean by dodge them in the back end?
>
> There’s code in gnetlist that allows a back end to alias refdes and netname values that violate its rules.
Rather than rewriting them, it would be better to just trap them and
give a reasonable error message. This would be less good than a
gschem that catches them immediately, but much better than the current
situation. Incidentally I've been meaning to look into the script you
contributed a while back that does something like this with refdes,
just haven't gotten to it yet.
>>>> 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.
>>>
>>> I completely disagree. The toolkit’s job is to enable the user to do what they need, not to get in their way.
>>
>> 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.
No, it means having the tools in the toolkit work in a reasonably
consistent way by default. The toolkit argument is a really poor
excuse for massive and pointless inconsistency between tools. There's
no real reason for it and people who run into it for the first time
are just going to think it's really sloppy.
>> 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’re making.
>
>>
>>>>> 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
>>>>
>>>> So what? In the meantime you haven't confused the heck out of users
>>>> for no real gain.
>>>
>>> You don’t know what other users need, so you can’t say “no real gain”. No real gain for you, maybe.
>>
>> What ~90% of users need is for pcb to work as well as possible.
>
> A guess without real data. But regardless, that’s the "tyranny of the majority”. It’s not acceptable that pcb users wish to take away the freedom of the rest of us. Pcb’s problems need to be solved either on pcb’s side of the interface, or by exploiting geda-gaf’s support for scripted optional features.
It's an educated guess that you've acknowledged yourself elsewhere,
and no one want to take away anything from you.
>> 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’t merely pcb-centrict, it’s also English-centric.
It's true that I hate the bs political correctness of knee-jerk UTF
use in places where it causes problems. That's not english-centric
it's solid-design-centric. UTF-8 causes problems for all non-trivial
software and I've seen too many attempts to throw it in without
anything being ready to think it's a good idea to do that.
>> 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’t shove it down other user’s throats.
Well all I'm asking for is that plus enabling it as a sensible
default. I haven't worked on gschem at all but perhaps you could
contribute the stuff to do it at the back end of gschem if you think
that's the place.
Britton
- Raw text -