delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/02/21/23:55:02

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=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=EC3jmdLK95NZpuWZgij/l6Ek5tlm89jNx2D91xHevyA=;
b=hnC3oyN0LlsgJhHq4teevLEKN9atiwrwHMXMztR0qb9KI0GqTimMFbRhFL0uTT0IIo
yIoQWcchvt9zfpawjgzCUS/nn357cNrf+9ivB0rm2rA84yH577jDFXRJES+CLJ+wF3HF
Hewyj3frQtrHkEh1Out2XoL/a0OhUt3nY/sj4Y9hK37Ttlj5bqa+yu3zNbVb+MBpC79G
8gGDQby7Z9c+TleXyB9+QgNX7tefnH3jmewMIYmtC196gJXZP1Yo4iHPRumhgiBD2F4j
yys0w5+pcHxASjEu4bdHiHD24/ZUlGuFGGP3y5YUgbQZaF+eISbTxk+kmdP7QGA3WzkG
tGnA==
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:content-transfer-encoding;
bh=EC3jmdLK95NZpuWZgij/l6Ek5tlm89jNx2D91xHevyA=;
b=XmLqb2e9YjWvXwZ2E4OSF7qIMX56bIZIq0VpLiBsAa47AG8wSxfQToGmZ61RgCYc9W
U5GBTJbQr+zxPZioJhsSRx6MumwGeMM8HPLDbAc9CU2EwX0qercUC1OAicAt+vfUxPa0
oY3NWUeH2jUymulwjmoTXZehYUciZXjiU10BMlv2XwewcKJCneDhgm1UxKV0PMfU66zM
j8H0ustRPMQh4SZM4w+2HvIBDJ2KJ2PDjJZhsYpdu+bqxhfye57XBDdUrKTwDo4uiCzJ
EKKLX+XP86gRtL+lltOhozwmxHUNjTBzdahaN4Mv7hqw/dwW5DycIv5ngDtpU4jHyXPj
q9pQ==
X-Gm-Message-State: AG10YOQTjE4DeJdZT0Vc2TsOvF+qFZpUEFtKAqaVqLgDgnGQLOZEmqNd3DdBfFz9GNVsKWBdixgAHmX8UXlFNw==
MIME-Version: 1.0
X-Received: by 10.28.92.195 with SMTP id q186mr9514696wmb.37.1456116847734;
Sun, 21 Feb 2016 20:54:07 -0800 (PST)
In-Reply-To: <AB351427-7E08-4412-A796-03E850F2411A@noqsi.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>
<CAC4O8c9jr_b376SpuUk5HrJApP1c75oxsEBemn-i_xtC-rt-Zw AT mail DOT gmail DOT com>
<201602162032 DOT u1GKWL7Y005291 AT envy DOT delorie DOT com>
<CAC4O8c-ig=0UVAqagNXH_DBmC9uVQDu3Y1Gx7LBGmRCo0-_kVQ AT mail DOT gmail DOT com>
<E75ECBB6-14E7-437A-B374-E0CF86BDFF1A AT noqsi DOT com>
<CAC4O8c8z4JiJr=mgA+co4pX-yxu_pVsXpeKRYqneuxZNnYqh8g AT mail DOT gmail DOT com>
<AB351427-7E08-4412-A796-03E850F2411A AT noqsi DOT com>
Date: Sun, 21 Feb 2016 19:54:07 -0900
Message-ID: <CAC4O8c8ejSN3GrmB1Zw=Dx9Pm-3Y0jwjNs=yjmwgsqcoVW5ACw@mail.gmail.com>
Subject: Re: [geda-user] pcb import schematic crash, parantheses in netname
From: "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u1M4sC3H028338
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

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 -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019